[Web-SIG] WSGI for HTTP/2.0 ?

[Cory Benfield]

On 20 September 2014 15:17, Benoit Chesneau <bchesneau at 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