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

On 23 Oct 2013, at 11:51 pm, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 22/10/2013 8:18 p.m., Ilari Liusvaara wrote:
>> 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"

If we want to do WebSockets over 2.0 (and that’s been discussed many times), the assumption AFAIK has been that iit’ll be a new protocol identifier. A new method would be problematic for many reasons.

>> - 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)?
> 
> Yes these were more what I was referring to than CONNECT. Currently the HTTP/1.1 proxies can relay such Upgrade to a custom upstream service that performs it. The proposal as it stands will remove that ability for HTTP/2.
> 
> Yes I know it sounds very close to CONNECT behaviour, but it *is* subtly different.
> 
> The case which I'm recalling is two company POP locations using HTTP proxies (Squid at one end at least) to relay traffic over port 80 in HTTP form. When the devices in one POP are hardware embeded and report in some foreign non-HTTP protocol. The proxy closest to them has a separate translator device it relays what appear to be normal HTTP requests to and sometimes gets back a mix of HTTP final status or 101 for the end-to-end response in some gobbledygook. Either way none of the regular HTTP proxy can natively translate nor tell whether the 101 is the right response to deliver to that particular request and the Upgrade: contents can only be generated properly at the client.

This sounds like protocol abuse, or at the very best, a horrible idea. We don’t have to support every pathological use of HTTP (thank goodness).

> I am thinking a mechanism supporting this style of use-case will be necessary and could be quite useful for two main reasons:
> * non-CONNECT methods allocate safety, idempotency and other handling semantics properties to the opaque tunneled data without revealing anything in it directly.
> * it helps enable the purging of CONNECT from both HTTP/2 and HTTP/1
> 
> Amos

--
Mark Nottingham   http://www.mnot.net/

Received on Friday, 25 October 2013 03:20:45 UTC