Re: [hybi] #6: HTTP Upgrade in relation to the WebSocket protocol

[Greg Wilkins <[e-mail]>]

I think it is really important to make a very clear separation of the
websocket protocol for an established websocket connection and for the
protocol used to establish that connection.

I would expect that over time there could develop several ways of
establishing websocket connections, with HTTP upgrade being the first
technique, but then I do see a good use-case for a websocket only
handshake like Scott has described.  Eventually there may be TLS
dependent mechanisms as well.

If we clearly separate out the wire protocol from the connection
establishment, then we can be very clear about what information is
needed from the handshake by the established connection and what
information is purely part of the particular handshake and security
mechanisms that might be particular just to HTTP upgrade (for
example).

If websocket does eventually get it's own port(s), then I think it
would be highly desirable to have a handshake that does not look like
HTTP at all.   Having HTTP-like on other ports will at best be
confusing, but at worst will result in some actually running real HTTP
servers (with websocket capabilities) on the Websocket ports, thus
importing all the security concerns of HTTP to the new ports.

cheers





On 20 July 2010 04:20, Scott Ferguson <[e-mail]> wrote:
> Roderick Baier wrote:
>>
>> Hi
>>
>> How could a WebSocket client detect if there is port sharing with HTTP or
>> not? I'm using WebSockets without HTTP, HTML, JavaScript and so on. From my
>> point of view there is no HTTP upgrade handshake, it's just a WebSocket
>> handshake that looks like HTTP.
>>
>>    "... not required if no port sharing is going on. In this case there is
>> no HTTP from which to Upgrade into WebSockets. There would simply be
>> WebSocket protocol over a dedicated port."
>>
>> What is "simply WebSocket protocol"? You'll still need an opening
>> handshake for resource, sub-protocol etc.
>
> Perhaps something along the lines of the discussion we had earlier, which
> might look like:
>
>  http://hessian.caucho.com/websockets/draft-ferg-hybi-websockets-latest.txt
>
>  The client handshake is a HELLO control frame that looks like the
>  following:
>
>    %x80.02.00.86 WebSocket/1.0
>    url: ws://example.com:880/sample/resource
>    origin: http://example.com/launchpage.php
>    protocol: tictactoe.example.com/1.0
>    <Stream data follows>
>
>  The server handshake is a HELLO control frame that looks like the
>  following:
>
>    %x80.02.00.32 WebSocket/1.0
>    protocol: tictactoe.example.com/1.0
>    <Stream data follows>
>
> -- Scott
>
>
>>
>> Best regards
>> Roderick
>>
>>
>>
>> hybi issue tracker schrieb:
>>>
>>> #6: HTTP Upgrade in relation to the WebSocket protocol
>>>
>>> --------------------------------------+-------------------------------------
>>>  Reporter:  g_e_montenegro@…          |       Owner:          Type:
>>>  enhancement               |      Status:  new
>>>  Priority:  major                     |   Milestone:     Component:
>>>  websocket-requirements    |     Version:      Severity:  Active WG Document
>>>        |    Keywords:
>>> --------------------------------------+-------------------------------------
>>>  Specify along the lines of RFC2817, namely, that the HTTP handshake is
>>> to
>>>  be used only if there is port sharing with HTTP, but is, of course, not
>>>  required if no port sharing is going on. In this case there is no HTTP
>>>  from which to Upgrade into WebSockets. There would simply be WebSocket
>>>  protocol over a dedicated port. See http://www.ietf.org/mail-
>>>  archive/web/hybi/current/msg02175.html. Also clarify that support for
>>> port
>>>  sharing mode of operation MUST be defined by the spec, but that it
>>> remains
>>>  optional operationally. It is not clear what is the use case for a
>>>  websocket completely independent of HTTP.
>>>
>>
>> _______________________________________________
>> hybi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hybi
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>