Subject: [hybi] Why HTTP Compliant

From: Greg Wilkins <[email-masked]>
Date: Tue, 1 Jun 2010 12:39:23 +0100

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.

regards

---

From: "Simon Pieters" <[email-masked]>
Date: Tue, 01 Jun 2010 15:04:36 +0200

> 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

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 1 Jun 2010 16:04:55 +0100

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 <[email-masked]> wrote:
> The client is required to ignore unknown headers in the handshake (at least
> in -76, I don't know about -75):
>
> [[

---

From: James Graham <[email-masked]>
Date: Tue, 01 Jun 2010 17:13:30 +0200

>     protocol.  The only options available in this version are the ...

That is explicitly non-normative text. The normative requirements are 
the ones that Simon mentioned, specifically Step 41 of the client 
handshake, which says:

"""
Any other name
     Ignore it.
"""

> the handshake should fail.

That's not what the spec says.

---

From: Wellington Fernando de Macedo <[email-masked]>
Date: Tue, 01 Jun 2010 12:15:37 -0300

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

Perhaps something like this in the handhake should be enough, shouldn't
be?

Upgrade: WebSocket/76

---

Wellington Fernando de Macedo

MSN: [email-masked]

Engenharia de Computação

Telefone: +55 (16) 8144.8607

Em 01/06/2010 12:04, Greg Wilkins escreveu:

Simon,

cheers

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

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

[[

--
Simon Pieters
Opera Software

_______________________________________________
hybi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/hybi

---

From: "Simon Pieters" <[email-masked]>
Date: Wed, 02 Jun 2010 09:51:36 +0200

>    protocol.  The only options available in this version are the ...

This text is non-normative.

> the handshake should fail.

Indications from the editor are also non-normative. :-)

> at least some implementations of chromium do implement a ban on extra  

Maybe you could file a bug? http://code.google.com/p/chromium/issues/list

> But I can't tell you exactly what versions of the draft they implement

It looks like -75 in chrome dev 6.0.408.1.

> (gee a

I don't see how it would help you in this case (you would still have to  
write the same code to make Chrome happy).

-- 
Simon Pieters
Opera Software

---

From: "Simon Pieters" <[email-masked]>
Date: Wed, 02 Jun 2010 10:17:02 +0200

> I agree that there are parts of the spec that imply arbitrary headers

They're acceptable in the sense that a conforming client would ignore  
them. They're not acceptable in the sense that servers are conforming if  
they send them.

[[
Sending the server's opening handshake

When a client establishes a WebSocket connection to a server, the server  
must run the following steps.
...
Send the following fields to the client. ...
]]

> ws version  string or user-agent header would be really really  

I don't see how it would help you in this case.

-- 
Simon Pieters
Opera Software

---

From: Bruce Atherton <[email-masked]>
Date: Fri, 04 Jun 2010 19:39:29 -0700

I am neither a browser developer or a server developer, so I may just be 
missing something. But I have to say that the current debate 
flabbergasts me. Here is my understanding of what you would have to do 
to write a server that can handle both HTTP and Websockets if you change 
the -00 spec so it didn't stay HTTP compliant until you upgrade the 
connection:

     -> GET /demo HTTP/1.1   # Claim is made that this is an HTTP 1.1 
compliant client

     server: Ok, I'll go into my HTTP handling code and treat this as an 
HTTP request

     -> Garbage Data  # Client was lying, it is really some other protocol

      server: This may be a bad HTTP request (which means I should throw 
an exception to go to my error handling code), but on the other hand 
maybe the client is a liar and this is some other protocol I support. If 
so, I need to keep this garbage data in case it is needed by the real 
protocol. How much data? Can't just store it all as that could lead to a 
DOS. So the HTTP handling code needs to know about other protocols like 
Websocket, and keep track of as much data as it may need. It may also 
improve performance to know about the configuration of other parts of 
the server, in case lying protocols like Websocket aren't deployed on 
this instance, in which case I can go to the error handling code 
immediately.

Really? You guys are writing a standard for a protocol, and you think it 
makes sense to require the client to lie about the protocol it talks? 
This goes beyond ironic and into surreal territory.

But you guys are smart, so maybe I am just missing something. Maybe 
writing server and proxy code really wouldn't be as insanely complicated 
as it looks like it would be. Maybe having lying clients is a really 
good idea. I sure don't see it, though.

> I don't see how it would help you in this case.

Because writing code that can choose between dealing with A or B is much 
simpler and cleaner than code that has to handle both A and B without 
knowing which it is handling. See above.