Subject: [hybi] Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt

From: Patrick McManus <[email-masked]>
Date: Thu, 26 Oct 2017 13:32:10 -0400

This is an updated based on the direction discussed.. I'm kind of on the
fence about whether its better. Its nice there is no h1 in there.

---------- Forwarded message ----------
From: <[email-masked]>
Date: Thu, Oct 26, 2017 at 1:30 PM
Subject: New Version Notification for
draft-mcmanus-httpbis-h2-websockets-01.txt
To: Patrick McManus <[email-masked]>

A new version of I-D, draft-mcmanus-httpbis-h2-websockets-01.txt
has been successfully submitted by Patrick McManus and posted to the
IETF repository.

Name:           draft-mcmanus-httpbis-h2-websockets
Revision:       01
Title:          Bootstrapping WebSockets with HTTP/2
Document date:  2017-10-26
Group:          Individual Submission
Pages:          9
URL:            https://www.ietf.org/internet-drafts/draft-mcmanus-httpbis-
h2-websockets-01.txt
Status:         https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-
websockets/
Htmlized:       https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-
websockets-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-mcmanus-
httpbis-h2-websockets-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-mcmanus-httpbis-h2-
websockets-01

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

---

From: John Fallows <[email-masked]>
Date: Thu, 26 Oct 2017 21:47:11 +0000

Hi Patrick,

Many thanks for spearheading this latest effort to define WebSocket over
HTTP/2, it's really encouraging to see the progress.

I recall from the early days of the WebSocket protocol design, probably
around the time we moved it from W3C HTML5 to IETF HyBi, that the client
handshake required sending additional content after the GET w/ Upgrade
HTTP/1.1 request.

This approach led to increased implementation complexity because the
HTTP/1.1 layer on the server now needed to know how to special case the
WebSocket usage of GET. It was also a bit trickier than desired because
that special case processing of GET now spanned over headers and some
initial content.

Ultimately, that approach was dropped in favor of a single request-response
to define the WebSocket handshake over HTTP/1.1, with no additional request
payload needed to process the handshake, making the implementation simpler
and with better abstraction layering.

The current proposal for WebSocket over HTTP/2 seems to be following a
similar approach to that described above at the moment, with the HEADERS
frame (requiring special-case processing of CONNECT) and first DATA frame
both needed to process the server-side WebSocket handshake over HTTP/2.

Suggest we instead fold the origin and relevant RFC-6455 defined HTTP
headers into the HEADERS frame for simplicity, recognizing as Mark noted
that CONNECT is not really intended for use directly at the origin server,
and instead use a TUNNEL method with corresponding :protocol pseudo-header,
where the value of the TUNNEL :protocol pseudo-header drives the
expectation of additional HTTP/2 headers that should be present.

[[ From Client ]]                        [[ From Server ]]

                                            SETTINGS
                                            ENABLE_TUNNEL_PROTOCOL = 1

HEADERS + END_HEADERS
   :method = TUNNEL
   :protocol = websocket
   :scheme = https
   :path = /chat
   :authority = server.example.com:443
   origin = http://www.example.com
   sec-websocket-protocol = chat, superchat
   sec-websocket-version = 13

                                            HEADERS + END_HEADERS
                                            :status = 200
                                       sec-websocket-protocol = chat

   DATA
   WebSocket Frames

                                            DATA + END_STREAM
                                            WebSocket Frames

   DATA + END_STREAM
   WebSocket Frames

Note also that the scheme is "https" rather than "wss" because the HTTP
request is still "https" until *after* the TUNNEL has been established, and
the TUNNEL protocol being selected is based on :protocol header rather than
the :scheme header.

Hope this is helpful and interested to hear your thoughts and feedback.

Kind Regards,
John Fallows
CTO, Kaazing

On Thu, Oct 26, 2017 at 10:32 AM Patrick McManus <[email-masked]>
wrote:

> URL:
> https://www.ietf.org/internet-drafts/draft-mcmanus-httpbis-h2-websockets-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-websockets/
> Htmlized:
> https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets-01
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-mcmanus-httpbis-h2-websockets-01
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-mcmanus-httpbis-h2-websockets-01
>
> Abstract:
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
-- 
*John Fallows*
CTO*  |  *📞+1.415.215.6597
*----------------------------------------------------------------------*
KAAZING >|<  when real-time matters™
kaazing.com/kwic <http://www.kaazing.com/kwic>  |  Blog
<http://blog.kaazing.com/>  |  Twitter <https://twitter.com/kaazing>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 27 Oct 2017 10:07:32 +1100

I think that John is right here.  Packing the websocket handshake into DATA
frames is more complicated than just using the headers.  The main
difference then between this handshake and the websockets one is:

* it's HTTP/2
* it might use a different method (CONNECT or TUNNEL rather than GET)
* it uses :protocol instead of Upgrade

I still lean toward CONNECT for this, despite reservations about the subtle
difference between usages (proxy vs. origin).  A natural lightweight
implementation of this has the server add proxy code that forwards the
tunnel to a websocket server.  That proxy would need to perform the
old-school 6455 handshake with the websocket server, but could construct
that from the headers of the CONNECT request.  The handling of the header
might be different, but the DATA frames are handled just like a CONNECT
tunnel.  That said, there is enough difference here to justify a different
method.

If you do use CONNECT, then you can define a default for :protocol of "tcp"
so that there is some sort of regularity to the overall structure and
people can build properly generic routing.

One thing that using :protocol suggests to me is that we need a new status
code for this, just in case someone asks for an unsupported protocol.  And
you probably want a registry for :protocol values (yay).

On Fri, Oct 27, 2017 at 8:47 AM, John Fallows <[email-masked]>
wrote:

> Ultimately, that approach was dropped in favor of a single
> request-response to define the WebSocket handshake over HTTP/1.1, with no
> additional request payload needed to process the handshake, making the
> implementation simpler and with better abstraction layering.
>
> and instead use a TUNNEL method with corresponding :protocol
> pseudo-header, where the value of the TUNNEL :protocol pseudo-header
> drives the expectation of additional HTTP/2 headers that should be present.
>
> the TUNNEL protocol being selected is based on :protocol header rather
> than the :scheme header.
>
>> Subject: New Version Notification for draft-mcmanus-httpbis-h2-
>> websockets-01.txt
>> URL:            https://www.ietf.org/internet-
>> drafts/draft-mcmanus-httpbis-h2-websockets-01.txt
>> Status:         https://datatracker.ietf.org/
>> doc/draft-mcmanus-httpbis-h2-websockets/
>> Diff:           https://www.ietf.org/rfcdiff?
>> url2=draft-mcmanus-httpbis-h2-websockets-01
>>
>> Abstract:

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Oct 2017 10:39:23 +1100

On 27 Oct 2017, at 10:07 am, Martin Thomson <[email-masked]> wrote:
> 
> I still lean toward CONNECT for this, despite reservations about the subtle difference between usages (proxy vs. origin).  A natural lightweight implementation of this has the server add proxy code that forwards the tunnel to a websocket server.  That proxy would need to perform the old-school 6455 handshake with the websocket server, but could construct that from the headers of the CONNECT request.  The handling of the header might be different, but the DATA frames are handled just like a CONNECT tunnel.  That said, there is enough difference here to justify a different method.

Just to give some context as to why I don't think it's a subtle change -- consider OWASP's mod_security CRS, which is the basis of most WAF products. It has baked-in assumptions about the semantics of CONNECT; e.g.,
  <https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/e4e0497be4d598cce0e0a8fef20d1f1e5578c8d0/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf>

That is pretty widely deployed, and just one example. Don't assume that HTTP is just a two-party protocol, even over HTTPS.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Andy Green <[email-masked]>
Date: Fri, 27 Oct 2017 07:40:36 +0800

On 10/27/2017 05:47 AM, John Fallows wrote:

> frame (requiring special-case processing of CONNECT) and first DATA 
> frame both needed to process the server-side WebSocket handshake over 
> HTTP/2.
> 

While I think the first draft, second draft or this suggestion are 
already good enough and get the result of eliminating the tcp + tls 
setup for ws needed today, I also thought that was what was going to 
happen in the second draft.

> that CONNECT is not really intended for use directly at the origin 
> server, and instead use a TUNNEL method with corresponding :protocol 
>     :authority = server.example.com:443 <http://server.example.com:443>
> request is still "https" until *after* the TUNNEL has been established, 
> and the TUNNEL protocol being selected is based on :protocolheader 
> rather than the :schemeheader.
> 

This is also simpler for me in two ways, a) headers remain headers and 
b) we don't need a new state machine to parse the DATA before it becomes 
ws traffic... DATA is only used to carry the tunnelled traffic which is 
better.  If you use a funky :method + :protocol or similar if a new 
pseudoheader makes trouble, no need for a DATA probe to upset things 
that don't understand.  Things that didn't understand and think they are 
getting a normal h2 stream will either kill the stream on the, to them, 
illegal method, or if not will kill the stream on the first DATA anyway 
because -->

The spec still needs to touch on the changes it is making to h2 DATA 
frames, it assumes it is inheriting generic bidirectional transport from 
h2, but it isn't.  H2 DATA kills the stream if it comes outside of 
whatever was told for content-length: on both sides, and eg h2spec 
requires you to enforce that.  So the spec requires changes in DATA 
handling implementation for upgraded streams and should note it.

It should probably note there is no relationship between H2 DATA frames 
and the tunneled content, and that the DATA frames may be refragmented. 
It wouldn't hurt to notice that WINDOW_UPDATE is still required / applies.

-Andy

---

From: Martin Thomson <[email-masked]>
Date: Fri, 27 Oct 2017 16:01:27 +1100

>   <https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/e4e0497be4d598cce0e0a8fef20d1f1e5578c8d0/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf>

I found this message quite obtuse (and that file worse), but what I
think you are saying is that an origin server might treat CONNECT
specially in a way that might make a new method easier to deploy.
That's a fine argument for a new method.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Oct 2017 16:03:04 +1100

> That's a fine argument for a new method.

We work in a field of jargon and extreme specialisation. You should try talking to those browser folks sometime...

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 27 Oct 2017 19:59:51 +1300

On 27/10/17 12:40, Andy Green wrote:>
> handling implementation for upgraded streams and should note it.

AIUI, Content-Length remains optional in h2 as it was in 1.x. The h2 
equivalent of Transfer-Encoding:chunked is being used by wss. Just a 
stream of DATA frames in both directions terminated by the END_STREAM 
flag instead of a specific Content-Length value.

Amos

---

From: Andy Green <[email-masked]>
Date: Fri, 27 Oct 2017 15:32:05 +0800

On 10/27/2017 02:59 PM, Amos Jeffries wrote:
>> frames, it assumes it is inheriting generic bidirectional transport 
>> from h2, but it isn't.  H2 DATA kills the stream if it comes outside 
>> of whatever was told for content-length: on both sides, and eg h2spec 

h2spec tests for these

         8.1.2.6. Malformed Requests and Responses
           ✔ 1: Sends a HEADERS frame with the "content-length" header 
field which does not equal the DATA frame payload length
           ✔ 2: Sends a HEADERS frame with the "content-length" header 
field which does not equal the sum of the multiple DATA frames payload 
length

> flag instead of a specific Content-Length value.

Well, that is banned in h2, but I guess you are right, if there is no 
content-length: it can just end on END_STREAM and there's no problem... 
it's my misunderstanding I guess.

-Andy

---

From: Patrick McManus <[email-masked]>
Date: Fri, 27 Oct 2017 06:33:21 -0600

thanks for the feedback.. start with a tightly scoped issue first:

> the TUNNEL protocol being selected is based on :protocol header rather

I don't think so.. there is no https target URL in play here.  7540 8.1.2.3
talks about non http schemes allowing the use of HTTP to interact with
non-http services this way.

---

From: Patrick McManus <[email-masked]>
Date: Fri, 27 Oct 2017 11:48:57 -0400

On Thu, Oct 26, 2017 at 7:40 PM, Andy Green <[email-masked]> wrote:

>
>
> While I think the first draft, second draft or this suggestion are already
> good enough and get the result of eliminating the tcp + tls setup for ws
> needed today,
>
>
The IETF - seeking consensus on how to skin a cat.

---

From: John Fallows <[email-masked]>
Date: Fri, 27 Oct 2017 16:42:52 +0000

Hi Patrick,

There seems to be no requirement to change the scheme to wss for a
functional handshake using TUNNEL method plus :protocol header with value
websocket.

In the example, the target URL used by the WebSocket on the wire would be
https://server.example.com/chat. The cross-origin security checks (etc) are
enforced by HTTP-specific validation of the request headers prior to
processing the TUNNEL method semantics. If the validation fails, then the
request never became a WebSocket. Only after a successful HTTP response is
provided can the pair of HTTP/2 streams be considered a WebSocket.

In the earliest days of the WebSocket protocol design, there was strong
emphasis on using a constrained form of HTTP/1.1 to describe the WebSocket
handshake, which in part contributed to creation of the schemes "ws" and
"wss" because it wasn't really HTTP per se.

Even after this was cleaned up to be a fully HTTP/1.1 compliant handshake,
as part of the work in IETF HyBi, the "ws" and "wss" schemes remained in
use on the client (only) but were deliberately not exposed on the wire.

Having separate schemes for protocols that must start out life as HTTP
forces questions about port defaulting for those schemes. Since the "ws"
and "wss" schemes ended up being treated the same as "http" and "https" in
terms of port defaulting, there doesn't seem to be much value in
propagating the "wss" scheme to the server especially when the :protocol
header is present with value "websocket".

Hope this is helpful.

Kind Regards,
John Fallows
CTO, Kaazing

On Fri, Oct 27, 2017 at 5:33 AM Patrick McManus <[email-masked]>
wrote:

> I don't think so.. there is no https target URL in play here.  7540
> 8.1.2.3 talks about non http schemes allowing the use of HTTP to interact
> with non-http services this way.
>
>
> --
*John Fallows*
CTO*  |  *📞+1.415.215.6597

---

From: Patrick McManus <[email-masked]>
Date: Fri, 27 Oct 2017 13:13:59 -0400

> functional handshake using TUNNEL method plus :protocol header with value

I'm not changing the scheme. It was also wss in http/1.1 as well - its just
that scheme does not typically appear on the wire in that protocol. My
reference to 7540 8.1.2.3 explicitly talks about non http schemes (ftp is
the most common). That doesn't make CONNECT/TUNNEL non http.. it just means
http is being used to interact with a non-http service..

> https://server.example.com/chat.
>

no.. the target url is wss://server.example.com/chat and this is a
definition of how to use h2 to access that service. This document doesn't
say anything about how to access an https:// schemed url. If the URL were
https://server.example.com it would be rejected by a websocket client which
requires ws or wss. PAC evaluation also expects ws/wss schemes.

> The cross-origin security checks (etc) are enforced by HTTP-specific
> validation of the request headers prior to processing the TUNNEL method
> semantics. If the validation fails, then the request never became a
> WebSocket. Only after a successful HTTP response is provided can the pair
> of HTTP/2 streams be considered a WebSocket.
>

maybe you're confusing protocol with scheme?

> use on the client (only) but were deliberately not exposed on the wire.

whether or not the scheme is on the wire is a property of http - not
something hybi was ever in a position to standardize. (thus the 'cleanup'.)

one weird note of 7230 5.3.2 requires that servers MUST accept absolute
form requests even though clients are forbidden from sending them to
non-proxies. The absolute form here would be wss://.. so this is an h1
thing too it just wasn't obvious.

> header is present with value "websocket".

you can of course imagine :protocol changing to be websocket2 with the
scheme not changing.

---

From: Patrick McManus <[email-masked]>
Date: Fri, 27 Oct 2017 13:25:12 -0400

On Thu, Oct 26, 2017 at 7:07 PM, Martin Thomson <[email-masked]>
wrote:

> code for thi

the existing, inherited, CONNECT rule is that 2xx means OK and anything
else means no tunnel. Is defining something better than 501 going to help
the client do something useful?

s, just in case someone asks for an unsupported protocol.  And you probably
> want a registry for :protocol values (yay).
>
>
ha! So I actually re-used the existing Upgrade registry for this. Was that
too rude? I also coming around to naming the pseudo-header :upgrade for
simplicity sake even though its not a great descriptor without a lot of
context.

---

From: John Fallows <[email-masked]>
Date: Sat, 28 Oct 2017 09:44:37 +0000

Hi Patrick,

Thanks for taking the time to address my feedback - comments inline below.
:-)

On Fri, Oct 27, 2017 at 10:14 AM Patrick McManus <[email-masked]>
wrote:

>> functional handshake using TUNNEL method plus :protocol header with
>> value websocket.
>>
>
> I'm not changing the scheme. It was also wss in http/1.1 as well - its
> just that scheme does not typically appear on the wire in that protocol.
>

This one is subtle.

Imagine if the client JavaScript API had elected to use:
  new WebSocket("https://example.com/chat", ["chat", "superchat"])

instead of:
  new WebSocket("wss://example.com/chat <https://example.com/chat>",
["chat", "superchat"])

then absolutely nothing about the wire protocol would have needed to change
for HTTP/1.1 WebSocket.

Interestingly, one of the original WebSocket handshake response headers
called WebSocket-Location, with ws[s] scheme URL, was removed as part of
the cleanup to use HTTP/1.1 proper.

As mentioned, the invention of the ws and wss schemes were born from not
using HTTP/1.1 proper from the beginning, including initially having
non-HTTP default ports such as 81 for ws instead of 80.

Server-Sent Events protocol deems it sufficient to offer a GET method
with accept
= text/event-stream header in the HTTP request, just as WebSocket protocol
deems it sufficient (in this proposed feedback) to offer a TUNNEL method
with :protocol = websocket pseudo-header in the HTTP request.

Although the origins of the WebSocket protocol design initially diverged
from HTTP, after the convergence on HTTP/1.1 proper, there was no remaining
justification for the "ws" and "wss" schemes from a network protocol
perspective, so they became a client-side concept enforced by the WebSocket
API and used by Proxy Auto-Configuration (PAC).

I'm suggesting we keep the "wss" scheme as a client-side concept, but also
avoid propagating it into the HTTP/2 network layer unnecessarily. Including
it just forces the server to pretend the :scheme = https anyway, e.g. the
server needs to know about :scheme = wss explicitly to treat it as https
while still processing HTTP layer semantics, such as cross-origin security.

>From an abstraction layering point of view, only WebSocket should depend on
HTTP, not the reverse.

My reference to 7540 8.1.2.3 explicitly talks about non http schemes (ftp
> is the most common). That doesn't make CONNECT/TUNNEL non http.. it just
> means http is being used to interact with a non-http service..
>

Good point - I went back and re-read RFC 7540, section 8.1.2.3 regarding
the :scheme pseudo-header (copied below).

*:scheme is not restricted to http and https schemed URIs. A proxy or
gateway can translate requests for non-HTTP schemes, enabling the use of
HTTP to interact with non-HTTP services.*

I understood this to mean that an HTTP GET request with scheme ftp could be
translated by an HTTP/2 proxy or gateway to a certain usage of FTP wire
protocol, such as file retrieval, while an HTTP POST request with
scheme ftp might
be translated as file upload via FTP wire protocol.

That desired translation of HTTP <=> FTP is captured by the :scheme = ftp
pseudo-header.

Since we are not trying to translate between HTTP primitives and WebSocket
protocol primitives, the use of :scheme = wss doesn't seem quite right.

> https://server.example.com it would be rejected by a websocket client
> which requires ws or wss. PAC evaluation also expects ws/wss schemes.
>

I think you missed my point - sorry, my fault.

I was trying to draw a clear distinction between a particular WebSocket
client implementation requirement (W3C territory) and the WebSocket
protocol requirement (IETF territory).

>From a network protocol perspective, all HTTP requests aimed at a
particular origin server, whether they use GET method or the proposed TUNNEL
method, would seem to logically have the same http or https scheme.

Singling out TUNNEL method with :protocol = websocket to present a
different :scheme = wss just seems to introduce more questions due to the
divergence from :scheme = https from the network protocol perspective.

Unlike a protocol, which represents a single layer in a protocol stack, a
scheme often unpacks to multiple protocol layers forming a protocol stack.
For example, the https scheme unpacks to http over tls over tcp.

In HTTP/2, transmitting :scheme = https describes the protocol stack up to
and including HTTP/2 itself. For example, this makes it easier for the
server to construct URLs that can be passed back to the client, where they
can be unpacked into a protocol stack consistent with the original HTTP/2
request.

If the server is processing the TUNNEL method with :protocol = websocket HTTP/2
request, and :scheme = wss is included, it is not accurately representing
the protocol stack up to and including HTTP/2, because the WebSocket
protocol handshake has not yet completed.

Say, at the HTTP/2 layer of the protocol stack, the server wants to issue a
302 redirect to path /chat2 in absolute form. It might most naturally
construct the redirect location using a consistent :scheme, :authority and
in this case replacement :path. However, with :scheme = wss the constructed
location would not be correctly formed as it would be requesting an HTTP
redirect to wss://example.com/chat2.

Instead the HTTP/2 layer at the server would need to know to pretend :scheme
= wss was really :scheme = https so it could send the redirect to
https://example.com/chat2 as intended. Then the client HTTP/2 layer would
need to somehow infer that the redirected request should send :scheme
= wss even
though the redirect URL had scheme https.

Alternatively, the HTTP/2 layer at the server would actually send the
redirect to wss://example.com/chat2, and then expect the HTTP/2 layer at
the client to understand how to follow that redirect as if https and
presumably include :scheme = wss.

Putting :scheme = wss on the wire forces a tight coupling between the
HTTP/2 and WebSocket subsystems for non-obvious benefit, while the tight
coupling can be avoided by putting :scheme = https on the wire instead.

> maybe you're confusing protocol with scheme?

No, they are quite distinct as described above.

The problem with sending :scheme = wss at the HTTP layer is that it
represents a promise of what will happen after the HTTP layer instead of
the current state up to and including the HTTP layer. That promise of
what's to come is already captured by the :protocol = websocket pseudo-header
so :scheme = wss doesn't appear to be adding much value.

> thing too it just wasn't obvious.

That interpretation doesn't seem consistent with RFC-6455, section 4.1
regarding absolute form (copied below).

*The "Request-URI" part of the request MUST match the /resource*
*        name/ defined in Section 3 (a relative URI) or be an absolute*
*        http/https URI that, when parsed, has a /resource name/, /host/,*
*        and /port/ that match the corresponding ws/wss URI.*

WebSocket servers should accept https://... as absolute form (not
wss://...), then process the Upgrade: websocket handshake without
attempting to change the meaning of the HTTP layer before the handshake has
completed.

Section 4.1 seems to make it clear that the intended scheme on the wire is
https for secure WebSocket connections.

If HTML5 or a client SDK in any other language decided to formalize sse as
the scheme to denote Server-Sent Events URLs, it would have no bearing on
the HTTP network traffic to setup an SSE event stream because it is a
client-side API contract that is not needed by the protocol layer.

IMHO, the wss scheme is an equivalent client-side API contract that is
equally not needed by the protocol layer.

> you can of course imagine :protocol changing to be websocket2 with the

Looking forward to hearing your perspective.

Kind Regards,
John Fallows
CTO, Kaazing

>> CTO*  |  *📞+1.415.215.6597 <(415)%20215-6597>
*John Fallows*
CTO*  |  *📞+1.415.215.6597

---

From: Patrick McManus <[email-masked]>
Date: Sat, 28 Oct 2017 21:17:47 -0400

+Alexey

> *        and /port/ that match the corresponding ws/wss URI.*

That's really interesting and is the only argument I find at all
compelling.Thanks.  Basically its saying that the URI of the GET is not the
websockets URI used in other places such as the cache and the pac. Which is
totally insane imo.

Given that H1 doesn't ever let you send an absolute URI to an origin server
that's a total nop of a statement. I'm not feeling particularly bound by it
if it is just broken and not used. I'm not sure I'm even willing to put my
name on continuation of it :)

Maybe Alexey, as 6455 author, can weigh in on what the target-uri was meant
to be.. but none of this is changing my mind on what it needs to be. You're
connecting to a wss:// target; the scheme is therefore wss://. That doesn't
mean it can't be carried on h2 or quic (if there were a definition) and it
doesn't mean its scheme changes when it is.

(as for redirects, yes the redirect needs to be to wss.. otherwise the
client should fail the connection as non ws[s] uris are not legal for
websocket clients.. as for the same server getting a mixture of schemes
that's something h2 is meant to support.. that's why the scheme is
explicit.).

---

From: Anne van Kesteren <[email-masked]>
Date: Sun, 29 Oct 2017 09:37:09 +0100

On Fri, Oct 27, 2017 at 7:13 PM, Patrick McManus <[email-masked]> wrote:
> I'm not changing the scheme. It was also wss in http/1.1 as well - its just that scheme does not typically appear on the wire in that protocol. My reference to 7540 8.1.2.3 explicitly talks about non http schemes (ftp is the most common). That doesn't make CONNECT/TUNNEL non http.. it just means http is being used to interact with a non-http service..

FWIW, we do change the scheme from the API perspective:
https://fetch.spec.whatwg.org/#websocket-protocol (details in section
6.2). The reason for that is 1) the handshake is a simple HTTP request
2) it makes it a lot easier to share HSTS, CSP, Mixed Content logic,
etc. So by the time it gets to the protocol there's no ws/wss. I think
ws/wss was largely a legacy thing from when we still thought it
wouldn't require HTTP at all.

-- 
https://annevankesteren.nl/

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 30 Oct 2017 14:10:14 +0900

Hi,

Thank you for working on the draft. I am happy to see WebSockets
coming to HTTP/2, and I like that the proposal tries to make changes
caused by the transition minimal.

The biggest issue I wonder if we can continue using HTTP/1 headers for
WebSocket parameter negotiation (e.g., Sec-WebSocket-Version,
Sec-WebSocket-Protocol), instead of sending them in DATA frames.

The reason I ask this is because unless we keep them as headers, it
would become impossible to implement a ws-on-h2 to ws-on-h1 proxy
without dealing with the details of the WebSocket protocol.

In HTTP/1, it has been possible to implement a HTTP proxy that
supports WebSockets, without the knowledge of sub-protocol
negotiation. This is because all the parameters were negotiated
through the use of the HTTP headers, and a proxy could simply forward
them as-is. All the thing that a proxy has been required to do is to
look at the Upgrade header and the status code, and start running a
bi-directional tunnel once the upstream server sends a 101 response.

With the -01 proposal, the same feature is retained only when a proxy
forwards from ws-on-h2 client to a ws-on-h2 server. In the case of
ws-on-h2 client connecting to ws-on-h1 server (or ws-on-h1 client
connecting to ws-on-h2 server), the proxy needs to convert
WebSocket-specific values sent in DATA frame to a HTTP header (or
vice-versa).

I wonder if this is a necessary complication. If not, I would prefer
to continue sending all the headers necessary for WebSocket
negotiation in HTTP/2 as well.

-- 
Kazuho Oku

---

From: Patrick McManus <[email-masked]>
Date: Mon, 30 Oct 2017 16:56:20 -0400

I think the consensus is to move the websockets parameters (sub-protocol,
etc..) in h2 HEADERS. -02 will reflect that.