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

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 <pmcmanus@mozilla.com>
wrote:

> thanks for the feedback.. start with a tightly scoped issue first:
>
> On Thu, Oct 26, 2017 at 3:47 PM, John Fallows <john.fallows@kaazing.com>
> wrote:
>
>>
>> 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.
>>
>
> 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
*----------------------------------------------------------------------*
KAAZING >|<  when real-time matters™
kaazing.com/kwic <http://www.kaazing.com/kwic>  |  Blog
<http://blog.kaazing.com/>  |  Twitter <https://twitter.com/kaazing>