[hybi] Comments about draft-13

[Iñaki Baz Castillo <[e-mail]>]

Some doubts about draft 13:


1)

-------------------------------
  1.6.  Security Model

          6.  If the response includes a "Sec-WebSocket-Protocol" header field,	
 	       and this header field indicates the use of a subprotocol that was	
 	       not present in the client' handshake (the server has indicated a	
 	       subprotocol not requested by the client), the client MUST _Fail	
 	       the WebSocket Connection_.  (The parsing of this header field to	
 	       determine which extensions are requested is discussed in	
 	       Section 9.1.)
---------------------------------

Why is this text speaking about "extensions"? do I miss something?



2) Sec-WebSocket-Extensions BNF grammar still relies on RFC 2616
"implied *LWS". Please, don't reference it. Pure ABNF does not allow
it, it's just a hack in RFC 2616. Instead, change the current text:

---------------------------
9.1.  Negotiating Extensions

   A client requests extensions by including a "Sec-WebSocket-
   Extensions" header field, which follows the normal rules for HTTP
   header fields (see [RFC2616] section 4.2) and the value of the header
   field is defined by the following ABNF.  Note that unlike other
   section of the document this section is using ABNF syntax/rules from
   [RFC2616], including "implied *LWS rule".  If a value is received by
   either the client or the server during negotiation that does not
   conform to the ABNF below, the recipient of such malformed data MUST
   immediately _Fail the WebSocket Connection_.

         Sec-WebSocket-Extensions = extension-list
         extension-list = 1#extension
         extension = extension-token *( ";" extension-param )
         extension-token = registered-token
         registered-token = token
         extension-param = token [ "=" token ]
---------------------------


with this:

---------------------------
9.1.  Negotiating Extensions

   A client requests extensions by including a "Sec-WebSocket-
   Extensions" header field, which follows the normal rules for HTTP
   header fields (see [RFC2616] section 4.2) and the value of the header
   field is defined by the following ABNF.  If a value is received by
   either the client or the server during negotiation that does not
   conform to the ABNF below, the recipient of such malformed data MUST
   immediately _Fail the WebSocket Connection_.

         Sec-WebSocket-Extensions = extension-list
         extension-list = 1#extension
         extension = extension-token *( SEMI extension-param )
         extension-token = registered-token
         registered-token = token
         extension-param = token [ "=" token ]
         SEMI  = SWS ";" SWS;
         SWS  = LWS?;
---------------------------

Of course, the same should be changed in "4.3 Collected ABNF for new
header fields used in handshake" as it repeats the
Sec-WebSocket-Extensions ABNF !!



3) Section 4.2.2 does include nothing about a 4XX HTTP response code
for the case in which the WS clients offers N WS subprotocols and the
server supports no one of them. Current text states that the server
MUST reply 101 without Sec-WebSocket-Protocol, so the client would
then MUST Fail_The_Connection.

There has been a long thread recently suggesting that in that case
(and just in *that* case) the server whould *reject* the GET request
with a *specific* HTTP status code which would mean "I don't support
any of your suggested WS protocols, so I cannot accept the WS session
because I have no idea what we are supposed to speak".

This is a new protocol, so feel *free* to create a new "HTTP" response
code for this case, maybe:

  488 WebSocket SubProtocol Not Supported

As I explained in other thread, this status code could help the human
user and the client application developer to realize that his software
is not up-to-date with the service requeriments ("your programm is too
old, upgrade please").




Regards.




-- 
Iñaki Baz Castillo
<[e-mail]>