Re: [hybi] Ticket#1 Http Compliance

[Scott Ferguson <[e-mail]>]

Greg Wilkins wrote:
> Maciej Stachowiak wrote:
>   
>> On May 13, 2010, at 2:53 AM, Greg Wilkins wrote:
>>     
>>> telnet is not HTTP compliant as I can telnet to a
>>> HTTP server and do all sorts of illegal stuff.
>>>       
>> Can you give an example that's relevant to WebSocket? Is there anything in a 
>> current or previous draft that's HTTP compatible but not HTTP compliant?
>> That would make it easier to assess the practical impact of this change.
>>     
>
> I believe the current -76 handshake could be described as HTTP compatible,
> but it is not HTTP compliant.
>   
Since -76 and HTTP don't even use the same encoding (-76 is UTF-8, while 
HTTP is US-ASCII with ISO-8859-1 used, but obsolete), I'm not sure 
calling them "compatible" is helpful.

The WebSocket handshake needs to be a valid HTTP request. If it's 
possible to create a valid WebSocket handshake that's not a valid HTTP 
request, then we have a problem, whether we call it "compatible" or not.
> There is also a restriction on the server that it's only
> valid responses to a handshake is to either accept with
> a 101 or to close the connection.  A compliant HTTP server
> should be able to respond with any compliant HTTP response.
> The websocket specification can say that websocket clients
> can ignore all non-101 responses and close the connection,
> but they cannot require that a HTTP server act contrary
> to the HTTP specification simply because a client made
> some mistake in the formulation of their websocket URL (for
> example).
>
> In order to claim websocket compliance, I do not want to
> have to change my server so that every URL that receives
> a bad websocket upgrade has to close the connection without
> sending some legal HTTP error response (eg 400 or 404).
>   
Agreed. This is a big issue. The server must be allowed to return a 
valid HTTP response rejecting the Upgrade request.

Actually, if WebSockets is using HTTP/80 for the handshake, it really 
needs a valid HTTP response on rejected requests and header errors. It's 
just not reasonable to require servers to produce an invalid HTTP 
response if it sees an Upgrade: WebSocket, when the rest of the request 
is normal HTTP.

Clients need to handle valid HTTP rejections anyway, because they need 
to respond properly to normal HTTP server responses, e.g. if the 
WebSocket service goes away or moves.

-- Scott