[whatwg] WebSockets API feedback

[Ian Hickson]

(Note that the WebSockets protocol is being developed by Ian Fette in the 
context of the HyBi working group at the IETF, and not by the WHATWG. The 
discussion here is limited just to API issues.)

On Sun, 20 Feb 2011, Bruce Atherton wrote:
>
> According to the spec, establishing a connection is done through the 
> Websocket object constructor on a background thread. This results in the 
> possibility that a connection could fire its open, error, and/or close 
> events before the user can set a handler for these events.

While it's true that tasks for those events might get queued before the 
listeners are attached, it doesn't actually matter, because so long as the 
script attackes the listeners before the event loop next spins, the events 
will not be dispatched before the listeners are attached.

In other words, so long as you hook the events in the same script as you 
create the object, you're fine.


> Is there a reason not to have a separate open() call?

There's always a reason not to have separate calls: the less API surface, 
the simpler the API, the simpler the implementations, the simpler the 
testing, the smaller the attack surface, the fewer the potential number of 
bugs, and so forth.


On Mon, 21 Feb 2011, Toni Ruottu wrote:
>
> I believed that the browser is expected to somehow magically delay the 
> events until a callback has been registered. At least that is how it 
> seems to work at the moment. The specification could be clearer about 
> this.

It's not magic, it's the event loop. The spec is entirely thorough about 
it already. Follow the links for "queue a task" and related terms.


On Mon, 21 Feb 2011, Robert O'Callahan wrote:
> On Mon, Feb 21, 2011 at 2:34 PM, Bruce Atherton <bruce at callenish.com> 
> wrote:
> > 
> > Perhaps you are reading a different spec than I am. The only language 
> > I see about queuing tasks involves changing the ready state on the 
> > Websocket object. There is nothing in there about waiting until a 
> > block of other Javascript code has run before making any other event 
> > callbacks.
> 
> http://dev.w3.org/html5/websockets/#feedback-from-the-protocol For every 
> event in that section, the user-agent must queue a task to fire the 
> event. None of the other sections describe any events.
> 
> > Let me see if I follow the "perfectly clear" line of reasoning you are 
> > using. Your assumption is that a Websocket connection will only be 
> > loaded in an event handler like window.onload.
> 
> In HTML5-compliant user-agents, all Javascript runs in some task of the 
> HTML5 event loop. That task must run to completion before other tasks 
> queued by the user-agent will run.
> 
> > No other events will be delivered until the current event handler 
> > finishes. And the event handler that creates the Websocket object will 
> > necessarily also be where the event handlers are set on the Websocket 
> > object. By making all of these assumptions, it becomes obvious that 
> > within a browser this API is safe for callbacks. Do I have that right?
> 
> Yes. You observe correctly that the Web author has to be careful to 
> ensure that the event handlers are set on the Websocket object during 
> the same task that created it. However, this is a fairly natural 
> requirement that is common in the Web platform.
> 
> > I am reminded of a joke about mathematicians. One argues that it is 
> > obvious that claim A follows from B. The other disagrees. After 
> > arguing for an hour, the latter finally agrees that A obviously 
> > follows from B.
> 
> Yeah :-). By "perfectly clear" I meant that the spec was "unambiguous", 
> rather than "obvious to the casual reader" :-).

It may be helpful to read the full WHATWG spec rather than the smaller W3C 
one, as the cross-references are easier to follow in the WHATWG spec:

   http://www.whatwg.org/specs/web-apps/current-work/complete/network.html#network


On Tue, 29 Mar 2011, Adam Barth wrote:
>
> In this HyBi thread:
> 
> http://www.ietf.org/mail-archive/web/hybi/current/msg06951.html
> 
> Folks are arguing that the WebSocket protocol should support HTTP 
> redirects during the handshake and that dealing with the security 
> consequences of redirects should be dealt with at the API layer. If/when 
> that occurs, we should update the API layer to deal with the security 
> consequences of the WebSocket protocol following HTTP redirects, 
> preferably by aborting any WebSocket connections that the server 
> attempts to redirect.

Done.


On Thu, 31 Mar 2011, Jonathan Chetwynd wrote:
>
> Websockets: dropped packets?
> 
> is there a 'guarantee' that packets will arrive?

Yes, WebSockets is based on TCP.


On Thu, 31 Mar 2011, Bob Gezelter wrote:
> 
> I do not believe that the TCP dependency is truly necessary or 
> beneficial. WADR, it would be far more appropriate to specify the needed 
> characteristics of the underlying transport. As an example, the earliest 
> versions of MTP (RFC 772) -- the predecessor of SMTP have successfully 
> taken this approach to specification.

I recommend bringing this up with the hybi group.


> In a recent posting to my blog, Ruminations, I suggested that the 
> WebSocket protocol specification be segregated into multiple RFCs, to 
> separate the TCP-related implementation issues from the underlying 
> protocol.

That's rather the opposite direction than I would recommend (I'd merge the 
protocol and API back into one spec, personally, and merge that with the 
rest of HTML while we're at it...), but it's up to the hybi group at this 
point.

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