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

[Jamie Lokier <jamie at shareable.org>]

Greg Wilkins wrote:
> 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.
> 
> When processing headers of a response, jetty mostly encodes them directly
> into the output buffer as it iterates over them.

Why are you using HTTP code to implement WebSocket?

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

WebSocket specifies more than that.  It specifies the exact sequence
of octets to send.  So why hack around HTTP header sending code, just
to send a fixed sequence of octets?  Forcing the order isn't enough:
you have to ensure the upper/lower case choices are exactly right too.
Of course most HTTP header senders will pass through what you ask from
the application (but not all).

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

I suspect if it were put to a representative vote of informed
citizens, there'd be a near consensus _against_ the strict
octet-sequence specification :-)

But let's not pretend it 'breaks' existing HTTP code.

WebSocket, in it's current form, has virtually no connection with HTTP
except the initial octet sequence can be mistaken for a HTTP request,
so (imho) it's a mistake to try to repurpose HTTP code at all for it.

-- Jamie