Re: [hybi] Why HTTP Compliant

[Bruce Atherton <[e-mail]>]

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.

On 02/06/2010 1:17 AM, Simon Pieters wrote:
> On Tue, 01 Jun 2010 17:04:55 +0200, Greg Wilkins <[e-mail]> 
> wrote:
>
>> (gee a
>> ws version  string or user-agent header would be really really 
>> useful!!!!!!)
>
> 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.