Re: Microsoft pre-LCWD feedback on WebSocket API

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.


> 2) The second comment about the protocol string is editorial. There was 
> quite a lot of confusion about what the protocol string is used for and 
> whether a central registry would be needed for well-known protocol 
> strings. I don't believe this is intended or necessary but this suggests 
> that the language could be clearer. Perhaps an informative section 
> describing the expected use of the protocol string might be included.

Done (as an intro section in the protocol spec).


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


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


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


> 6) The send() method can both throw an exception in the CONNECTING state 
> or return an 'error' flag if in the CLOSED state. APIs that both have 
> return values and also throw exceptions commonly cause coding errors by 
> developers using them. For example, here web developers may fail to deal 
> with the CONNECTING state because on their test service they get an 
> almost immediate connection but once they deploy hitting this case 
> becomes much more common. We recommend choosing between exceptions or 
> return values but not both.

The exceptions are thrown for cases where there is a logic error, and the 
return value (not an error code, just the connection status) is used to 
handle expected events such as network errors.

Using exceptions for network errors is a bad idea because it would mean 
any use of the API would have to use exception handling.

Using a more elaborate return value to report logic errors also would IMHO 
not really lead to a clearer programming model in this case, since authors 
wouldn't be looking for those errors either, and would likely just treat 
it as a connection failure, leading to trying to reconnect, which would 
then cause increased load on the server -- an especially bad result, since 
the slow connection is likely to be caused by an overloaded server!

Using exceptions here sidesteps this since it is not expected that authors 
will catch the exception, and thus it will just report an error on the 
error console (useful for development) and abort the script, without 
preventing the connection from being established.


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


> 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_spec.3F

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

Received on Friday, 4 December 2009 01:20:15 UTC