Re: [hybi] -09: abstract and introduction

["Simon Pieters" <[e-mail]>]

On Wed, 15 Jun 2011 23:10:34 +0200, Peter Saint-Andre <[e-mail]>  
wrote:

> Section 1.3 says:
>
>    A JavaScript application cannot set a header starting with "Sec-" via
>    XHR.
>
> Why not? What is the nature of the restriction?

"Header names starting with Sec- are not allowed to be set to allow new  
headers to be minted that are guaranteed not to come from XMLHttpRequest."

http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#dom-xmlhttprequest-setrequestheader

> Section 1.3 says:
>
>    If the |Sec-WebSocket-Accept|
>    value does not match the expected value, or if the header is missing,
>    or if the HTTP status code is not 101, the connection will not be
>    established and WebSocket frames will not be sent.
>
> Do we really mean the following?
>
>    If the |Sec-WebSocket-Accept|
>    value does not match the expected value, or if the header is missing,
>    or if the HTTP status code is not 101, the browser MUST NOT
>    establish the connection and MUST NOT send WebSocket frames.

All of section 1 is non-normative so shouldn't contain any requirements.


> This paragraph is hard to read:
>
>    Conceptually, WebSocket is really just a layer on top of TCP that
>    adds a Web "origin"-based security model for browsers; adds an
>    addressing and protocol naming mechanism to support multiple services
>    on one port and multiple host names on one IP address; layers a
>    framing mechanism on top of TCP to get back to the IP packet
>    mechanism that TCP is built on, but without length limits; and
>    includes an additional closing handshake in-band that is designed to
>    work in the presence of proxies and other intermediaries.  Other than
>    that, it adds nothing.  Basically it is intended to be as close to
>    just exposing raw TCP to script as possible given the constraints of
>    the Web. It's also designed in such a way that its servers can share
>    a port with HTTP servers, by having its handshake be a valid HTTP
>    Upgrade request mechanism also.
>
> I suggest breaking it up into bullet points:
>
>    Conceptually, WebSocket is really just a layer on top of TCP that
>    does the following:
>
>    * adds a Web "origin"-based security model for browsers
>
>    * adds an addressing and protocol naming mechanism to support
>    multiple services on one port and multiple host names on one IP
>    address;
>
>    * layers a framing mechanism on top of TCP to get back to the IP
>    packet mechanism that TCP is built on, but without length limits
>
>    * includes an additional closing handshake in-band that is designed
>    to work in the presence of proxies and other intermediaries
>
>    Other than that, WebSocket adds nothing.  Basically it is intended
>    to be as close to just exposing raw TCP to script as possible given
>    the constraints of the Web. It's also designed in such a way that
>    its servers can share a port with HTTP servers, by having its
>    handshake be a valid HTTP Upgrade request mechanism also.

I'm not sure this text is accurate anymore now that we have extensions and  
whatnot.

> Section 1.7 says:
>
>    By default the WebSocket protocol uses port 80 for regular WebSocket
>    connections and port 443 for WebSocket connections tunneled over TLS
>    [RFC2818].
>
> I know this has been discussed on the list, but how can an entity
> discover if WebSocket is offered on ports other than 80/443? Would the
> web server use a redirect to do that? Could it define SRV records?

I don't think there's any discoverability. You can't know that WebSocket  
is offered on ports 80/443 either. I think the Web page that opens a  
WebSocket is supposed to know which port to use. (The WebSocket API  
doesn't allow redirects.)

-- 
Simon Pieters
Opera Software