Re: [hybi] Why HTTP Compliant

[Greg Wilkins <[e-mail]>]

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 <[e-mail]> wrote:
> On Tue, 01 Jun 2010 13:39:23 +0200, Greg Wilkins <[e-mail]> 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
>