W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Expect/Continue and Removing 1xx Final Status codes from HTTP/2

From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Date: Tue, 22 Oct 2013 10:18:07 +0300
To: Mark Nottingham <mnot@mnot.net>
Cc: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
Message-ID: <20131022071807.GA6853@LK-Perkele-VII>
On Tue, Oct 22, 2013 at 04:56:04PM +1100, Mark Nottingham wrote:
> Hi Amos,
> 
> On 15/10/2013, at 4:47 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:
> 
> > 
> > The proposal is fine from a HTTP/1->HTTP/2 gateway standpoint. But there are some issues that need to be clarified before I would be happy agreeing to it...
> > 
> > What is the proposal for replacing Upgrade+101 status in HTTP/2 ? Some kind of yet to be defined frame?
> 
> There will be no replacement on the wire; protocol negotiation is being moved "before" HTTP/2, and so we expect the negotiation mechanisms to be useful for several versions of HTTP.

What about websockets? Hybi WG has elminated some muxing features
waiting for HTTP/2.0 (or that's at least how I interpretted some comments
there).

Yes, defining "light"[1] version of websockets would be very easy:

- Method is "WEBSOCKETS"
- Sec-Websocket-Key and Sec-Websocket-Accept are not used.
- Upgrade is not performed.
- Masking is not performed nor required.
- Format of DATA frame:
  - First byte of websockets main frame header (type and reserved bits)
  - Everything after main frame header.
  - No padding.

But what other uses of Upgrade: are there (including non-standardized
uses)?

> > So what HTTP/2 feature is to be used to negotiate between two HTTP/2 peers for converting the stream to an opaque set of DATA and having the upstream perform the Upgrade?
> 
> I think you're making an argument that HTTP/2 needs something like CONNECT, not that we need Upgrade (if I understand correctly). And, maybe doing some endgame planning on how this protocol will work without HTTP/1 generally.

Saying that servers and proxies MAY respond to what looks like HTTP/1.X
request-line by something like:

505 HTTP/1.X not supported HTTP/2.0

And half-closing the connection?

HTTP/1.X request lines are regular, so that shouldn't be that hard
to implement.

> > I am generally in agreement with the removal of this one provided the texts is clear that this is not a *removal* as such, but a replacement with native HTTP/2 framing flow control meeting the same need. That will help prevent the obvious requests to get it "re-added". But the above question still does have to be met or HTTP/2 will be casuing more damage than broken HTTP/1 support already is.

What is the replacement for applications that POST/PUT large streams?
Having to buffer lots of data (I have seen this in one application,
it breaks if dataset is larger than the buffer)?

It gets even worse: The application may not be even aware of HTTP/2.0,
but using HTTP/1.1 proxy, and now the forged 100 breaks it (yes, it
would break if server was 1.0, but who uses 1.0+HTTP-AUTH?).



[1] Restrictions on extensions being:
- No extensions requiring main header changes.
  - Using RSV bits OK.
  - Adding extension header is OK if counted in size field.
- No extensions requiring >16,382 byte frame payloads.

The proposed payload compression extension does meet
those constraints. And one would expect most extensions
do.


-Ilari
Received on Tuesday, 22 October 2013 07:18:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:18 UTC