[whatwg] Websocket algorithmic specification

[Greg Wilkins]

Sorry for the cross post hybi/whatwg.
I raised these issues on hybi list, but there was no
specific response (probably due to the other issues
being debated there).

I think the issues below indicate ambiguities in the
spec.  I raised them as an argument to change away from
the algorithmic style of specification, but even if that
is not accepted, they need need to be somehow clarified
in this spec.



Error Handling
==============
The client side sentinel framing algorithm includes the
text in 4.2-2.-(second 2.):

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

Surely this text must either be copied to every data
read (for length framing and for both server side framings)
or (better) moved to a overall "If at any point during these
steps ..." type statement.


The phrase
   "If at any point during these steps a read is
    attempted but fails because the Web Socket connection is
    closed, then abort"

is repeated for both client side framing algorithms, but
is not included in the server side algorithms.

None of the framing algorithms specify how a timeout
should be handled.

Error handling for low resources, closed connections
and timeouts is probably best specified once rather
than repeated everywhere the algorithms say read.
But if it is to be specified in the algorithms, then
it needs to be thorough and consistent.



Bad lengths
===========

The length encoding currently allows for a length
of 0x80 0x80 0x80 .... to be sent forever.   This
is a nonsense length, but could be used for DOS
attacks on servers.   I think the 0x80 value should
be explicitly defined as an error if given as the
first byte of a length.

If the spec is to include error handling in it's
algorithms, then it should state that the length
loop can be terminated if the accumulated value
exceeds some maximum.



Definition of "Send"
====================
The specification algorithms use the phrase "send the
following bytes" frequently.   For example 4.1-5 says:

 send the following bytes to the remote server
 47 45 54 20

A literal reading of the spec would interpret that as
meaning that the bytes actually have to be sent, while
any sane implementation is going to append the bytes to
a buffer to be sent/flushed sometime later.

Does this mean that ws server could validly reject a
handshake as non compliant if these bytes arrived
in the same packet as the subsequent bytes?

I know this point sounds pedantic, but give that the
spec is already deliberately pendantic about HTTP header
ordering a uppercase/lowercase, it is best to be clear.
The meaning of send needs to be clarified and if algorithmic
style is to be maintained, perhaps flush points should be
included?



regards