Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt

Hey Andy - it sounds like my 2 mails on this thread mght not have been
posted to hybi? I'll try here with @mozilla.com addr. Thanks for the note.



On Sun, Oct 15, 2017 at 3:24 PM, Andy Green <andy@warmcat.com> wrote:

>
> 2)
> This simply isn't true,


thanks. I'll rephrase


> 4) The draft should spell out it carries ws payload unchanged in h2
> frames.


   Streams that have been successfully established as protocol tunnels
   proceed to establish and utilize the WebSocket Protocol using the
   procedure defined by [RFC6455
<https://tools.ietf.org/html/rfc6455>] treating the stream as if were
the
   connection in that specification.


Obviously there are approaches that could do far more significant things to
the protocol. This is a shim for bootstrapping 6455, otherwise 6455 remains
in tact.

5) Hybi originally did the ws handshake key dance with hashes to ensure
> there were no inadvertant ws handshakes


see 4.


> 6) If you make the ws key dance roundtrip optional, something to keep h1
> clients happy who don't know they're on h2, then you can PUSH_PROMISE a ws
> upgrade on a specific subprotocol unilaterally, eliminating roundtrips.  If
> you are serving html with a


you can only push safe methods. connect is not safe. Again, I agree you
could remove an rtt (or probably 2) with a different approach at a cost of
higher complexity and changes. That's not the target here.

\

> >Doesn’t the introduction of a new pseudo-header field violate RFC 7540
> >Section 8.1.2.1, which says endpoints MUST NOT generate new
> >pseudo-header fields?
> >
> >Or is the position that that MUST NOT implicitly applies only if there
> >are no negotiated extensions in use?
>
> That is a good point... won't a new Sec-whatever do?  Being able to use
> whatever it is in PUSH_PROMISE to unilaterally offer an unambiguous
> pre-upgraded ws stream would be very nice.
>

I answered this is a message that probably wasn't posted to hybi
https://lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/0034.html..
tl;dr; an opt-in extension lets you amend 7540 in ways that would be
protocol violations without the opt-in.

pseudo-headers are meant to control protocol level features and are unique
to that version of the protocol - so this helps ensure that the Sec- header
wasn't introduced by some other non h2 application .

-Patrick


> -Andy
>
> >Cory
> >
> >> On 15 Oct 2017, at 07:12, Patrick McManus <mcmanus@ducksong.com>
> >wrote:
> >>
> >> FYI - also see
> >https://github.com/mcmanus/draft-h2ws/blob/master/README.md
> >>
> >> Comments, expressions of interest, etc are very welcome.
> >>
> >>
> >> ---------- Forwarded message ----------
> >> From: <internet-drafts@ietf.org>
> >> Date: Sun, Oct 15, 2017 at 10:08 AM
> >> Subject: New Version Notification for
> >draft-mcmanus-httpbis-h2-websockets-00.txt
> >> To: Patrick McManus <mcmanus@ducksong.com>
> >>
> >>
> >>
> >> A new version of I-D, draft-mcmanus-httpbis-h2-websockets-00.txt
> >> has been successfully submitted by Patrick McManus and posted to the
> >> IETF repository.
> >>
> >> Name:           draft-mcmanus-httpbis-h2-websockets
> >> Revision:       00
> >> Title:          Bootstrapping WebSockets with HTTP/2
> >> Document date:  2017-10-15
> >> Group:          Individual Submission
> >> Pages:          7
> >> URL:
> >https://www.ietf.org/internet-drafts/draft-mcmanus-
> httpbis-h2-websockets-00.txt
> >> Status:
> >https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-websockets/
> >> Htmlized:
> >https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets-00
> >> Htmlized:
> >https://datatracker.ietf.org/doc/html/draft-mcmanus-
> httpbis-h2-websockets-00
> >>
> >>
> >> Abstract:
> >>    This document defines a mechanism for running the WebSocket
> >Protocol
> >>    [RFC6455] over a single stream of an HTTP/2 connection.
> >>
> >>
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> >submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> The IETF Secretariat
> >>
> >>
>
>