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

On 10/16/2017 04:38 AM, Patrick McManus wrote:
> 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 <http://mozilla.com> 
> addr. Thanks for the note.

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

Yes... it should probably spell that out for DATA though, something like:

"Once upgraded, the h2 stream is used to transport the ws frames by 
enclosing them in h2 DATA frames.  There is no specific relationship 
between h2 DATA fragment sizes carrying the ws frames and the ws frame 
sizes; the h2 frames may refragment the original ws frames arbitrarily, 
eg to meet mux latency goals across multiple streams.

Although the DATA frames used for encapsulation are not distinguishable 
from DATA frames used for h2 http transport, note unlike DATA frames 
used for http they are not restricted in either direction by 
content-length and they may appear in either direction continuously, 
until END_STREAM appears.".

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

Not suggesting to change that...

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

Well, it looks like you don't want to do it.  This thing would be an 
optional optimization it doesn't affect what you have at the moment.

PUSH_PROMISE has some restrictions as defined in RFC7450 8.2, like 
"Promised requests MUST be cacheable" which would need working around. 
It's also slightly different in that ws is bidirectional, normal 
PUSH_PROMISE the server manages delivering the promise or not, and the 
client can accept stuff to cache at any time or RST him.

But with ws PUSH_PROMISE content, there'd be a race between the script 
trying to instantiate the ws connection after the HTML was received so 
it has a context to use the ws link, and the server deciding to try send 
something.  It can be handled by defining the initial tx window to be 0 
for ws PUSH_PROMISE streams and the client must explicitly allow it to send.

Here's what I think it means for RTT... first the default as it is

Client    Server

  - SETTINGS                      - SETTINGS
  - GET /index.html
     - 200 HEADERS + DATA

  - :method CONNECT
       - 200 HEADERS

  - DATA ws handshake
     - DATA ws handshake final

  - DATA ...    - DATA...

So after the h2 link is up, he needs 3 x roundtrips to send some ws 
data.  With an optional PUSH_PROMISE that the client feels he can use...

  - SETTINGS                      - SETTINGS
  - GET /index.html
     - 200 HEADERS + DATA
     - PUSH_PROMISE ws contains
       ws handshake final

  - WINDOW_UPDATE (see below)
  - DATA ...
     - DATA...

It's just one (client -> server) or 1.5 (server -> client) roundtrips 
instead of 3.

Anyway if nobody else wants it, no point worrying about it.

-Andy

> \
> 
>     >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
>     <mailto:mcmanus@ducksong.com>>
>      >wrote:
>      >>
>      >> FYI - also see
>      >https://github.com/mcmanus/draft-h2ws/blob/master/README.md
>     <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 <mailto: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
>     <mailto: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 <https://www.ietf.org/internet-drafts/draft-mcmanus-httpbis-h2-websockets-00.txt>
>      >> Status:
>      >https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-websockets/ <https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-websockets/>
>      >> Htmlized:
>      >https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets-00
>     <https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets-00>
>      >> Htmlized:
>      >https://datatracker.ietf.org/doc/html/draft-mcmanus-httpbis-h2-websockets-00 <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 <http://tools.ietf.org>.
>      >>
>      >> The IETF Secretariat
>      >>
>      >>
> 
>

Received on Monday, 16 October 2017 02:39:43 UTC