Re: New Version Notification for draft-mcmanus-httpbis-h2-websockets-02.txt

On Mon, Nov 13, 2017 at 10:03 AM, Kazuho Oku <kazuhooku@gmail.com> wrote:

> The point I had missed is that END_STREAM is used as a signal to
> indicate the end of the request under all methods except CONNECT.
> OTOH, in WebSockets (or in any other protocol upgraded from HTTP), we
> would want to use the stream (without sending END_STREAM) to transfer
> the bidirectional communication.
>

Can this be one of justifications for sticking to CONNECT?

Given that CONNECT + :protocol is already different from CONNECT w/o
:protocol, my rough guess is that this wouldn't help proxy implementors so
much e.g. simplifying logic by using the same logic for CONNECT with and
without :protocol.

Or, more about concern of divergence from RFC 7540? I.e. it's good to rely
on the characteristics already given to CONNECT by RFC 7540.


> There are three possible solutions: a) use CONNECT (or define a new
> method that has the same characteristics as CONNECT; i.e. END_HEADERS
> marks end of the request), b) define a new mechanism for detecting the
> boundary between end of the HTTP request and the beginning of the
> payload of the upgraded bi-directional stream, c) use a new
> pseudo-header that instructs the server to consider END_HEADERS as the
> end of the request for any given method.
>

Interesting point!

I share the same feeling as you regarding the demand for asking the peer to
treat some bytes following END_HEADERS as a part of the request and the
rest as not. I can't come up with any use case and leaning toward not
introducing such a mechanism. I might be wrong though.