Subject: [hybi] Feedback on thewebsocketprotocol-22

From: Mark Nottingham <[email-masked]>
Date: Fri, 17 Jul 2009 12:08:49 +1000

Hi Ian,

As promised, some feedback. I think it's mostly editorial, except for  
the last one.

* I've already given feedback on the squid-dev list ("Hello from  
Mozilla" thread on <http://www.squid-cache.org/mail-archive/squid-dev/200907/ 
 >)  regarding the handshake and impact on HTTP infrastructure. I  
think all that's necessary here is some added text about the failure  
cases (which I think you're already starting to address in -23), and  
some adjustment to the text in the introduction (e.g., a pointer to  
the new section outlining the trade-offs/risks).

* 1.1 Security model: you frame the model in terms of browsers and Web  
pages. I think Websockets is potentially applicable to any restricted  
execution environment, not just Web pages.

* 1.2 Relationship to TCP/IP and HTTP: "It's" --> "Its"

* 3.1 Handshake: host, port, origin and resource name all need  
definitions/references. Without them, it's difficult to tell what the  
allowable ranges are; e.g., can a host contain non-ASCII characters?

* 3.1 Handshake, step 2: Can you speak to why this is limited to a  
host, and not (host, port)?

* 3.1 Handshake, step 3: Another thing to consider here is how  
WebSockets should be accommodated in proxy.pac; it's commonly used.  
E.g., define a new proxy type WEBSOCKETS in proxy.pac, and define a  
fallback to SOCKS then HTTPS then HTTP if it's not present.

* 3.1 Handshake, step 3: "If there was a password" --> "If proxy  
authentication [RFC2616] is used"

* Overall, at the risk of beating a dead horse, the algorithmic nature  
of this specification makes it difficult to answer questions about the  
protocol without building a state machine. I'd suggest that adding a  
section or two about the overall operation of the protocol and its  
various structures would help address this concern.

* Finally, AIUI the important features that WebSockets adds (Origin,  
assuring that other protocols aren't simulated, etc.) all happen  
during the handshake. As such, I wonder why this specification isn't  
just the handshake, falling back to a normal (possibly tunneled) TCP/ 
IP connection once the handshake has completed; it would be a lot less  
new things to understand and vet, and less constraining as well.

IIRC this question has been asked before, but I didn't see a reply; if  
there is one a summary or reference would be appreciated.

Thanks,

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

---

From: Ian Hickson <[email-masked]>
Date: Wed, 29 Jul 2009 23:39:57 +0000 (UTC)

On Fri, 17 Jul 2009, Mark Nottingham wrote:
> Mozilla" thread on 
> <http://www.squid-cache.org/mail-archive/squid-dev/200907/>) regarding 
> the handshake and impact on HTTP infrastructure. I think all that's 
> necessary here is some added text about the failure cases (which I think 
> you're already starting to address in -23)

Is the text adequate now?

> and some adjustment to the text in the introduction (e.g., a pointer to 

Since the two sections are on the same page, I haven't added the pointer 
-- someone reading the spec will see both sections soon enough.

> execution environment, not just Web pages.

It would have to be an execution environment that uses an Origin-based 
security model. I'm not aware of any other such mechanisms. Could you 
elaborate on what you would like the spec to say here?

> * 1.2 Relationship to TCP/IP and HTTP: "It's" --> "Its"

Fixed.

> allowable ranges are; e.g., can a host contain non-ASCII characters?

There's no allowable ranges -- this is just defining the protocol side of 
the API spec, which invokes this algorithm. These are just "parameters" or 
"variables", they aren't expected to be arbitrarily invoked.

I suppose I could add a separate section on "how to use this specification 
from another specification", where I define what the expected ways that 
the algorithms in this spec are to be invoked are. Would that help?

> * 3.1 Handshake, step 2: Can you speak to why this is limited to a host, 
> and not (host, port)?

Aren't system resources usually limited on a per-host basis, not per-port? 
I can make it port-limited if you think that's the better thing for DOS 
protection. I'm not an expert on this topic, by any means.

> fallback to SOCKS then HTTPS then HTTP if it's not present.

Good point. What's the spec for proxy.pac? I should probably just update 
that directly.

> authentication [RFC2616] is used"

That's just non-normative example text, I try to keep the example text 
colloquial so as to make the examples clearer to new readers.

> various structures would help address this concern.

I've added an introduction to the algorithm. Does it address your 
suggestion adequately?

> assuring that other protocols aren't simulated, etc.) all happen during 
> the handshake. As such, I wonder why this specification isn't just the 
> handshake, falling back to a normal (possibly tunneled) TCP/IP 
> connection once the handshake has completed; it would be a lot less new 
> things to understand and vet, and less constraining as well.

The framining is present so that we can expose this as an event-based 
protocol instead of a streaming-based protocol in the API. It would be a 
pain to require authors to have to implement buffering and piecing 
together of messages when we can just do it with trivial framing at the 
API level.

I've uploaded a new version of the spec.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 30 Jul 2009 03:12:41 -0500

> together of messages when we can just do it with trivial framing at the

I notice that in -28 (!), the security considerations section remains empty.  Has any thought been given to the impact of very large frames?  (Resource consumption DOS?)

--Martin

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Ian Hickson <[email-masked]>
Date: Thu, 30 Jul 2009 08:35:23 +0000 (UTC)

On Thu, 30 Jul 2009, Thomson, Martin wrote:
> > protocol instead of a streaming-based protocol in the API. It would be 
> > a pain to require authors to have to implement buffering and piecing 
> > together of messages when we can just do it with trivial framing at 
> > the API level.
> 
> I notice that in -28 (!), the security considerations section remains 
> empty.  Has any thought been given to the impact of very large frames?  
> (Resource consumption DOS?)

Good point. I've made a note to myself to make sure I mention this when I 
fill out that section.