RE: Microsoft pre-LCWD feedback on WebSocket API

Hi Ian,

Thanks for your response. I've included the feedback that I've captured from some groups at Microsoft below.

Cheers,

Adrian.

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.

> > 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. Our reviewers were reading the spec linked to from the pre-LCWD feedback call. Suggesting they in fact review a different document that combines a number of different specs from different working groups (and that is also huge in comparison) isn't very practical.

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

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

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

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

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

Received on Wednesday, 16 December 2009 06:16:57 UTC