Re: HTTP/2 and Websockets

On 26 November 2014 03:05:40 GMT+08:00, Martin Thomson <martin.thomson@gmail.com> wrote:
>On 25 November 2014 at 04:28, Yutaka Hirano <yhirano@google.com> wrote:
>>> a) rewriting intermediaries MUST read HEADERS
>>> b) if they see an UPGRADE header they do not know how to deal with,
>they
>>> must kill the stream
>>> This also covers "upgrade xxx-123" case for http2.
>>
>> We could ask for it, but I'm not sure if giving a special meaning for
>> "rewriting" is suitable from http/2 point of view and it is suitable
>to
>> request at this moment, given that http/2 is almost stabilized
>(not?).
>> cc: Martin.
>> We had a discussion about the capability check and agreed to use
>SETTINGS
>> frames.
>> http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/1114.html
>
>I don't see how Andy's request is feasible.  The way HTTP/2 is
>structured, intermediaries are permitted to collapse and re-assemble
>DATA as they choose.  You cannot rely on frame boundaries to remain.

It does not prevent http2 reframing nor does it rely on frame boundaries to remain.

But the approach of sticking a byte in front of each DATA after ws upgrade would mean the reframer would need to understand that stream had upgraded and reframing would mean sticking a flags byte at the front of the split frame, and eliding the then-superflous flags byte when combining them.

That's asking a lot of what might be a dumb http2 router or whatever I agree.

>To that end, you either do as suggested up-thread and force support by
>all intermediaries, or you add your own framing.

Yeah, although 'add your own framing' may be out of band by

 - using a different http2 frame type (which kills deployment), or

 - hiding the ws flags inside the DATA frame header (which needs http2 spec buyin),

or in-band by

 - tunelling ws completely as Willy says (which is inefficient bandwidth-wise and means nasty crap like masking lives on).

>I don't know if you have considered this...
>You could use CONNECT and only use the multiplexing features of the
>protocol.  A special CONNECT would be rejected by all but those that
>recognize it.  More so if you made the CONNECT pseudo-header fields
>include a ":scheme" of "wss", which is illegal.  I note that we don't
>identify what error/status is generated if you break that rule.

It sounds reasonable.  It was a regular suggestion on hybi to replace upgrade.  Honestly, I don't really know enough about the merits of either approach, although upgrade is what ws1 uses.

But I think the problem we identified about upgraded connections in http2 generally being negotiable, but that being divorced from the ability to pass data over them is a separate issue that needs addressing.  If native http2 has a way for intermediaries to veto upgrade activity they know they will make trouble on, that will be a better way to bound the problem than explicit buyin per-protocol.

-Andy

Received on Wednesday, 26 November 2014 01:01:19 UTC