W3C home > Mailing lists > Public > public-html@w3.org > July 2008

Re: websocket HTTP response parsing

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 06 Jul 2008 12:14:54 +0200
Message-ID: <48709B1E.4030502@gmx.de>
To: Ian Hickson <ian@hixie.ch>
CC: "public-html@w3.org" <public-html@w3.org>

Ian Hickson wrote:
>> As far as I can tell, it depends on specifics of the server 
>> implementation. I can easily imagine cases where it's the HTTP server 
>> that replies to the upgrade request, and control to the new server 
>> component passes only afterwards. In that case it could be hard to 
>> produce the specified byte sequence.
> 
> Yes, it may require careful work when the servers are updated.

So why make it harder than necessary?

>> Also, did you consider the impact of intermediates in the request path?
> 
> You mean, like proxies? Sure, the spec defines how to handle those.

What if they somehow modify the reason phrase? It would be outside the 
control of the server, and communication would break.

> ...
>> But it's more complex than it needs to be
> 
> It's a stream of bytes. It's longer than absolutely necessary, sure, but 
> how can it be more complex than necessary?

Ok, it's longer. What for?

>> and also contains plain english text that, as far as I can tell, doesn't 
>> serve any useful purpose.
> 
> Why is using the HTTP spec's recommended text a problem?

The HTTP spec doesn't recommend any specific text. The reason phrase is 
for human consumption only. For instance, there are servers known to 
vary it by Accept-Language or locale.

There's simply no point in putting it in, so why do it?

> Could you describe the actual practical problem you are concerned about?

Could you describe the actual practical problem because of which you're 
putting in a reason phrase?

BR, Julian
Received on Sunday, 6 July 2008 10:15:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:19 GMT