Re: [hybi] Why HTTP Compliant

ws version  string or user-agent header would be really really useful!!!!!!
Simon,

I agree that there are parts of the spec that imply arbitrary headers
are acceptable,
but it also says:

  Fields in the handshake are sent by the client in a random order; the
   order is not meaningful.

   Additional fields are used to select options in the WebSocket
   protocol.  The only options available in this version are the ...

Ian has indicated that this means that the presence of other headers means that
the handshake should fail.

It would be really good if I have misunderstood what he has said about this, but
at least some implementations of chromium do implement a ban on extra headers.
But I can't tell you exactly what versions of the draft they implement (gee a
ws version  string or user-agent header would be really really useful!!!!!!)

cheers

On 1 June 2010 14:04, Simon Pieters <simonp@opera.com> wrote:

On Tue, 01 Jun 2010 13:39:23 +0200, Greg Wilkins <gregw@webtide.com> wrote:

Ian has frequently said that HTTP Compliance is just a desire for
theoretical
purity.

But lack of HTTP compliance is causing me almost daily head aches with
our websocket work.

We are now supporting websocket in the cometd2 framework, and it is
working with both
-75 and -76 clients.

However, we also sometimes use a cross origin access control filter
that supports normal
long polling to the same cometd server from different origins without
the need for json callbacks
etc.

This filter follows the cross origin specification and sets the
   Access-Control-Allow-Origin
on HTTP responses, which of course breaks the websocket handshake.

So we now have to modify this  filter to have

 if (!websocket)
 {
   ...
 }

Easy enough to do, but the filter comes from a different project and and
in a
stable release.   Luckily it is open source.     So now while the fix is
simple,
i have to break encapsulation of websocket concerns and update another
project (or copy/modify code).

There are just going to be endless issues like this.

The handshake should just ignore arbitrary unknown headers rather
than breaking.

This is NOT a theoretical issue.

The client is required to ignore unknown headers in the handshake (at least
in -76, I don't know about -75):

[[
41. ... handle each entry in the fields list as follows:
...
↪Any other name
Ignore it.
]]

--
Simon Pieters
Opera Software

_______________________________________________
hybi mailing list
hybi@ietf.org
https://www.ietf.org/mailman/listinfo/hybi" rel="nofollow">https://www.ietf.org/mailman/listinfo/hybi