RE: Microsoft pre-LCWD feedback on WebSocket API

On Wed, 16 Dec 2009, Adrian Bateman wrote:
> On Thursday, December 03, 2009 5:20 PM, Ian Hickson wrote:
> > On Thu, 19 Nov 2009, Adrian Bateman wrote:
> > >
> > > 1) In the WebSocket constructor, we think it would make sense to 
> > > limit the optional protocol string to a set of characters that is 
> > > easier to secure. The UI never surfaces this string and having 
> > > something that doesn't require processing the full set of strings 
> > > into UTF-8 shouldn't be a significant restriction. We also think 
> > > that specifying length constraints would be useful. For example, 
> > > stipulating the minimum length that conforming implementations must 
> > > be able to handle. One suggestion was to re-use the same criteria as 
> > > a valid scheme name as defined in section 3.1 of RFC 3986.
> > 
> > I don't see why we'd make it _that_ restricted, but I do agree that it 
> > needs to be restricted to at least disallow non-ASCII characters and 
> > CRLF, since that would break the handshake. I've updated the spec 
> > accordingly.
> 
> Our general feeling was that having it be fairly restrictive was 
> unlikely to be problematic and it is easier to relax the constraints if 
> it becomes apparent that it is necessary than to try to constrain 
> further in future.

I don't think that's really a good reason to restrict things. XML tried 
that approach (over-restrict and relax later) and it caused all kinds of 
problems.

Generally speaking, it's when we start having extra conditions that 
implementations mistakes creep in, with the associated lack of 
interoperability, and potentially even security bugs. I'd really much 
rather keep everything really simple than have arbitrary restrictions.


> > > 3) The spec uses many terms that the HTML5 spec defines. As far as I 
> > > can tell, there isn't a definitive list of these. The 2.1 
> > > dependencies section notes that many concepts come from HTML5 but 
> > > not saying which ones seems insufficient for spec moving to Last 
> > > Call. Most of the people who looked at this spec had never looked at 
> > > HTML5 before and their feedback was simply that many terms were 
> > > undefined.
> > 
> > I recommend using the WHATWG "complete.html" version of the spec, 
> > which integrates all of HTML5 and both the Web Sockets API and Web 
> > Socket protocol specs (and a few others) into a single document:
> > 
> > http://www.whatwg.org/specs/web-apps/current-work/complete.html#network
> > 
> > The cross-references in that document mean that all the terms defined 
> > in HTML5 are clearly referenced.
> > 
> > I am hoping that we will be able to make the postprocessor generate 
> > appropriate cross-references even in the case of the split specs.
> 
> This seems like something that should be done before the spec proceeds.

gsnedders has said he's working on this, so I'll wait until he's done and 
then try to apply his work to this spec.

Failing that, would the approach I recently used in the Microdata draft be 
acceptable?

   http://dev.w3.org/html5/md/#terminology

It makes the cross-references in the spec all go to a single terminology 
section, which thus disambiguates which terms are defined in HTML5 and 
which are not.

Notwithstanding the way the spec is split at the W3C and the IETF, this 
really is all just part of the "complete.html" spec at the WHATWG. I don't 
want to duplicate the definitions everywhere, since then they'd start 
getting out of sync, which is a recipe for disaster.


> > > 4) In step 2 of the UA steps for the WebSocket() constructor, the 
> > > spec calls for an exception to be thrown if the user agent chooses 
> > > to block a well-known port. We think that web developers will often 
> > > miss this case because it will be hard to test the error case and 
> > > may be an unusual failure. We propose that the UA signal this 
> > > condition in the same way as failing to connect to a service which 
> > > will be much more common and more likely to be handled by web 
> > > developers.
> > 
> > Wouldn't this error be caught very early in development, when the 
> > connection just wasn't established?
> > 
> > It seems unlikely that non-hostile authors will ever run into this 
> > anyway, since they shouldn't be using these ports.
> 
> It's not clear that all user agents would impose the same rules so 
> there's no guarantee this would be caught. It's entirely possible 
> someone might legitimately host a WebSocket service on a well-known port 
> believing this to be an appropriate strategy without realising that some 
> user agents might block that.
> 
> Our feedback is that it is a best practice in library design to 
> encourage developers to handle unusual cases without the need to write 
> extra code. It is common for developers to measure the success of their 
> testing with code coverage - we prefer to avoid trying to get our test 
> teams to have to set up weird test beds to construct obscure test cases 
> to test unusual scenarios.

I don't really see how firing "onclose" is going to help in this case. If 
the author isn't going to catch this before shipping, why is it going to 
make a difference if the failure mode is that the script thinks everything 
is fine except the connection terminated early, vs the script dying early?

If anything, it seems like the latter is going to take more work to debug, 
since it would be reported as "I get disconnected!" which would lead to 
the authors investigating the problem on the server, rather than "the page 
breaks" which leads to the authors trying to test the page (where they 
will relatively quickly find the problem is that the browser isn't 
allowing the connection at all).


> > > 5) It is not clear precisely where the '"fail the Web Socket 
> > > connection" algorithm' is defined.
> > 
> > Section 4.3. "Closing the connection" of the Web Socket protocol spec.
> 
> I can't see the text "4.3" in the spec at 
> http://dev.w3.org/html5/websockets/. Am I looking in the wrong place for 
> section 4.3?

That's the Web Socket API spec. The "fail the Web Socket
connection" algorithm is defined in the protocol spec.

The two specs really should be read as one (and really are one -- they are 
only split into two because of W3C/IETF politics).


> > > 7) It is not clear exactly how to implement the bufferedAmount 
> > > property and be interoperable. Where is the queue of bytes not yet 
> > > sent? Is this at the application layer, in the networking stack, on 
> > > the network card, or somewhere else?
> > 
> > Any of the above that are likely to have significant caching ability. 
> > The idea is to make it possible to write code that doesn't 
> > oversaturate the network.
> > 
> > > We propose removing the bufferedAmount property.
> > 
> > What would you replace it with? We need _something_ to handle the case 
> > of rate-limiting an infinite amount of data (e.g. sending mouse 
> > position data as far as possible).
> 
> We don't believe that an arbitrary value for bufferedAmount leads to a 
> reasonable and interoperable approach to rate-limiting. If this is 
> necessary why leave it up to each web application to figure this out. 
> Why not have the API indicate whether or not it is happy to accept more 
> input?

Wouldn't that just be a one-bit version of bufferedAmount?


> Maybe an example showing how bufferedAmount should be used to avoid 
> oversaturating the network would be useful.

I have added a simple example of how to use it for the common case of 
sending data at about 20Hz without exceeding the speed of the network. 
I've not included the rarer case of saturating the network, but I wrote an 
example of what it might look like here:

   http://www.damowmow.com/playground/demos/websocket/saturate.html

It's relatively simple, but I don't think it's something we want people 
copying into their code everywhere, so I think it's best if we have only 
the more conservative example in the spec.


> > > I think we will have some other feedback more related to the wire 
> > > protocol than the API although changes to the protocol could 
> > > potentially impact the API. I'm not sure how the working group plans 
> > > to handle this interaction between the API draft and discussions 
> > > elsewhere about the protocol (I understand there is a proposal to 
> > > deal with the protocol in an IETF working group?).
> > 
> > I'm treating both specs as one, and treating feedback from the webapps 
> > list, the WHATWG list, and the hybi list as one. I encourage you to 
> > join the WHATWG and hybi lists if you are interested in keeping track 
> > of the discussions. Of course, some feedback might come from other 
> > sources, like blogs. The best way to track the spec is to follow the 
> > recommendations given in this FAQ entry:
> > 
> > http://wiki.whatwg.org/wiki/FAQ#How_can_I_keep_track_of_changes_to_the_sp 
> > ec.3F
> 
> If the specs should all be treated as a single spec then presumably they 
> should have the same status. I was under the impression adoption of the 
> WebSockets protocol into the IETF working group was at an early stage. 
> It seems premature to move the API spec to Last Call if the protocol 
> isn't at an equivalent stage.

They're both already at Last Call at the WHATWG.

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

Received on Sunday, 31 January 2010 07:00:19 UTC