Re: [hybi] Fwd: Web sockets and existing HTTP stacks

[Greg Wilkins <[e-mail]>]

Jamie Lokier wrote:

> The main spec editor believes WebSocket should intentionally fail when
> encountering a proxy etc. and the web application should fall back to
> some other method in that case, or simply not support those cases.
> 
> Needless to say, several people take the opposite view, that it should
> work over general HTTP infrastructure, but as that would make the
> protocol more complicated and simplicity is also a goal, there is no
> consensus.

All,

As an example of the problems resulting from this spec, I had some
hassle implementing websocket support within the Jetty codebase.

When processing headers of a response, jetty mostly encodes them directly
into the output buffer as it iterates over them.  However a few headers
are held back until all the other headers have been processed as
the values of other headers might influence the values imposed on
transport headers.    For example, the lack of a content-length
header might mean that a "close" value needs to be added to the
"Connection" header.    Thus Jetty delays generation of the connection
header until all the other headers have been processed.

This means the for Jetty responses, the connection header is normally
one of the last headers generated.

Unfortunately this breaks the websocket specification, which insists
on the Connection header being immediately after the Upgrade header
and before the other WebSocket- headers

I thus have had to put a special purpose hack in place deep in the
HTTP generation code for jetty - to not delay Connection header handling
if the response looks like a websocket upgrade response.  Alternately
I could refactor the generator to do two passes over the headers, or
use a special purpose generator just for this response.

However, it is my expectation that such special purpose hacks or
refactoring of existing working code will result in far more breakage
and security risks than any possible gain resulting from a strict
adherence to header ordering.

Existing HTTP code allows great flexibility in handling of headers
and most code will be written with this assumption.

Is there any consensus at all that strict header equivalence is
a reasonable thing for this specification to have and is worth
breaking the vast majority of existing HTTP code?

regards