Re: HTTP/2 and Websockets

On 21 November 2014 17:08:00 GMT+08:00, Yutaka Hirano <yhirano@google.com> wrote:
>On Fri, Nov 21, 2014 at 5:44 PM, Robert Collins
><robertc@robertcollins.net>
>wrote:
>
>> On 21 November 2014 20:03, Yutaka Hirano <yhirano@google.com> wrote:
>> >
>>
>> > I don't like the idea of using the existing DATA frame.
>> >
>> > 1. An intermediary must flush data when it sees an end of message
>(FIN).
>>
>> But intermediaries won't be buffering: they'll be forwarding as soon
>> as they can, since h2 is being established from the get-go as an
>> interactive protocol.
>>
>> Hmm... Is that specified?
>Are such buffering proxies prohibited explicitly?
>
>> IIUC we don't have such flag in the plain http2 (we had END_SEGMENT
>but it
>> > is gone). So "just move opaque DATA payloads around" is not enough.
>>
>> Why not? Any ws ignorant h2 proxy that holds buffers for
>indeterminate
>> periods because e.g. it wants to virus scan uploads/downloads is just
>> as likely to a) reject unknown frames or b) inspect and scan ws
>> frames. I don't see how we prevent that by using a custom frame.
>>
>> We can prevent the situation with WS_DATA, because a ws ignorant h2
>proxy
>must not transfer the custom frame.
>The spec says:
>  Implementations MUST discard frames that have unknown or unsupported
>types.
>
>Unable to communicate is better than relying on intermediaries that do
>not
>understand what they are doing, I think.

I think this approach will continue the tradition of there being no workable way to do this on http2.

Eg, adding a flag on http2 DATA for WS payload type seems to answer your objections... you reckon that's no longer possible at this point?

-Andy

>> 2. With explicit negotiation, I know that all peers in the
>communication
>> > path understand ws-over-http2 perfectly and there is no chance to
>>
>> The proposed negotiation in the draft I saw didn't guarantee that
>(see
>> my comments in this thread) because options isn't graph-capable: an
>> intermediary that is capable advertises its capability, not the
>> capability of peers on the other side of it, and no replacement
>> negotiation has been proposed that I've seen.
>>
>I will think more on this point.
>
>
>> > misunderstand DATA in http2 and DATA in ws2, in theoretically. In
>> reality,
>> > that is not true. The history of WebSocket is the history of
>battles with
>> > mis-implemented proxies (Note that the native WebSocket has the
>explicit
>> > negotiation but proxies modify payloads without understanding it).
>I
>> would
>> > like to reduce the possibility of such confusion.
>>
>> WebSockets' HTTP/1.1 upgrade hack was a clever way to avoid a new
>port
>> for a new protocol layered on top of 20 years of proxy evolution.
>> We're not *at all* in the same situation now, and I think we should
>> bear that in mind.
>>
>> -Rob
>>
>>
>> --
>> Robert Collins <rbtcollins@hp.com>
>> Distinguished Technologist
>> HP Converged Cloud
>>

Received on Friday, 21 November 2014 09:51:17 UTC