On 20 September 2014 15:17, Benoit Chesneau <bchesn...@gmail.com> wrote: > 1) HTTP 1.1 vs HTTP 2: > > - HTTP 1.1 and HTTP2 have quite the same high level syntax (methods, uri, > headers, ...) but the way the data is transported differs. (data are sent by > frames in HTTP 2).
Yes, this is correct. *In principle*, much of the way WSGI transmits information can remain exactly the same, at least from the perspective of working with HTTP/2. > - in HTTP 2, data can be encrypted and compressed. Not by default. HTTP/2 DATA frame compression got removed from the draft spec in draft-13. It's currently available in a draft extension, but it'll only ever be an extension to HTTP/2. HTTP/2 encryption is just the same as for HTTP/1.1: TLS. > At the application, things doesn't change that much. Everything can appear > like before. The only change is the PUSH feature. Server Push is important, but I think you've missed some really key points in HTTP/2 that are potentially valuable to expose at the application level. Firstly, HPACK provides special provision for marking some headers as 'never index'[0]. This is for security reasons, and is intended to signal that no-one should keep that header value in their header tables. We may well want to expose this functionality. Secondly, HTTP/2 DATA frames can be padded. Assuming padding remains in the spec (not guaranteed), this is another security feature that we may want to expose to the application. (Exposing this to application is kinda stupid, but we can't leave it to the server because it won't know what to pad and what not to pad.) Thirdly, we need to remember that HTTP/2 streams are flow controlled. This requires the design to very carefully consider how a response blocked by flow control behaves. Fourthly, the multiplexing is *prioritised*. This priority information may need to be accessible to the application in order to make decisions based on it. Fifthly, while HTTP/2 is *able* to handle the standard HTTP/1.1 request-response cycle, it needn't be *limited* to it. In particular, long-polling works a whole lot better in HTTP/2 because of fact that stream lifetime is potentially unlimited. Similarly, because streams are bidirectional it may become popular to use HTTP/2 streams as ad-hoc websocket connections. These are all suggestions that we shouldn't necessarily cleave too closely to the current WSGI paradigm. I'm sure I've missed some other things as well. What I wanted to highlight is that HTTP/2 is a subtle, complex protocol that is much more powerful than the one it replaces. We should very carefully consider how we approach a new WSGI specification, because we're going to be stuck with it for the next few years. I do think the idea of collating feedback is a good one, however. [0]: https://tools.ietf.org/html/draft-ietf-httpbis-header-compression-09#section-7.2.3 _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com