[hybi] Buffering and error handling (Was: Serf support for BWTP)

[Ian Hickson <[e-mail]>]

On Mon, 1 Feb 2010, Greg Wilkins wrote:
> 
> I believe that the algorithmic specifications that remain in the 
> document actually introduce a significant lack of clarity and ambiguity.
> 
> The algorithms if implemented as described, would have measurable 
> external artefacts.
> 
> For example, when section 4.1 - 5 says "send the following bytes to the 
> remote server 47 45 54 20", do I actually have to send them?  Or can I 
> buffer them with the following bytes.

I've clarified the spec to say that a node can delay arbitrarily long 
(e.g. for buffering) whenever a byte is to be sent.


> Would a server be justified in rejecting the handshake (on security 
> grounds?) because those bytes are not sent in their own TCP/IP packet?

A server can reject the handshake based on the phase of the moon, the time 
of day, the size of packets, anything. No justification is needed.


> The specification relies on assumed common practise and understanding 
> that "send" can actually mean "buffer and flush sometime later, perhaps 
> aggregated with previous and/or following sends".  Relying on assumed 
> interpretation is not a good thing for a spec.

Agreed. That's a good point. I have updated hte spec accordingly.


> Another issue is that only the client-side sentinel framing algorithm 
> says:
>               "If the client
>               runs out of resources for buffering the incoming data, or
>               hits an artificial resource limit intended to avoid
>               resource starvation, then it must fail the Web Socket
>               connection and abort these steps."
> 
> Does this mean that the serverside or client length framing cannot
> reject a connection based on resource limits?  Must this sentence be
> put into every step of the algorithm that says "read a byte"?
>
> Surely it would be better just to express this error handling 
> non-algorithmicaly?

Good point. In fact there is already a paragraph to that effect under that 
algorithm. I've removed the above text.


> In which case your point about "sanely define all the error handling 
> rules" does not stand up well to this example.

By "error handling" I mean logic, not arbitrary limits. e.g. how to parse 
data using an unknown frame type, or how to handle unknown headers, etc.


> There are numerous error handling cases not handled in your algorithms:
> 
>  + int or long  overflow if a very very large number is sent as a
>    frame length.
>  + what to do if a client sends for the length 0x80, 0x80, 0x80, ....
>    do we read and multiply forever or can we conclude that somebody
>    is messing with us?

These is handled by the aforementioned paragraph after the algorithm.


> In the client framing, we are allowed to abort "If no byte could be read 
> because the Web Socket connection is closed".  But the server is not 
> granted that permission.  What can we do if a read times out but the 
> websocket is not closed?

The server is granted blanket permission to close whenever it wants. 
("Servers may close the Web Socket connection whenever desired.", in the 
section titled "Closing the connection".)


> In fact I can see no sanely defined error handling in these algorithms 
> at all.  Can you point me to one example in section 4.2 or 5.3 that is 
> both complete, un-reliant on common sense interpretation and could not 
> be better and less verbosely defined in imperative style?

Step 2 of the "Data framing" algorithm for clients handles all frame 
types, including all 254 errorneous types.

I've designed the framing so as to minimise the number of possible 
errors, so it's true that there aren't many cases of error handling. The 
point is that behaviour is defined for all possible byte streams.

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