Re: websocket HTTP response parsing

Ian Hickson wrote:
>> But in that case the response to the upgrade request would still come 
>> from the HTTP server (I think), in which case it may not be possible to 
>> generate the exact octet sequence you specced...
> 
> Well, where it comes from depends on how the server is written. Since the 
> server has to be upgraded to handle WebSockets at all, it doesn't seem 
> unreasonable for it to be upgraded in the particular way required by the 
> spec today.

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.

Also, did you consider the impact of intermediates in the request path?

>>>> And also, why not require an empty reason phrase (which would get 
>>>> rid of having plain text messages in English hardwired into the 
>>>> protocol)?
>>> Given that the handshake blob is basically opaque, what's wrong with 
>>> having hardwired? The previous version had the handshake be just 
>>> "Hello" "Welcome", which is just as hardwired to English.
>> Well, it can't be HTTP and opaque at the same time, unless I'm missing 
>> something.
>>
>> If it really is opaque, just make it simple, instead of adding english 
>> text...
> 
> I don't understand the problem. It's opaque from the point of view of the 
> Web Socket protocol. It's intentionally HTTP-compatible so that it can be 
> used with an HTTP server if that is desired.

But it's more complex than it needs to be, and also contains plain 
english text that, as far as I can tell, doesn't serve any useful purpose.

BR, Julian

Received on Sunday, 6 July 2008 09:45:36 UTC