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

On Fri, Oct 27, 2017 at 12:42 PM, John Fallows <john.fallows@kaazing.com>
wrote:

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

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



>
> In the example, the target URL used by the WebSocket on the wire would be
> 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?


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

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.



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


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



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