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

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"
> - 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.

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

Received on Wednesday, 23 October 2013 12:52:06 UTC