Re: [hybi] WebSocket feedback

Vladimir,

GET's can have content.  It's just the browsers mostly don't send
content with GETs.

The server needs to consider the bytes of content before formulating
the accepting the upgrade request and sending the 101 response, so
it can't be considered as data in the stream after the 101.

regards

Vladimir Katardjiev wrote:
> I like this update, especially that the handshake is human-readable in
> the spec now. Caveat that I haven't implemented it yet so I guess proper
> feedback comes then.
> 
> On 4 mar 2010, at 08.25, Greg Wilkins wrote:
>>
>> If the handshake messages are to contain content, then they
>> MUST have headers to indicate the content length to be legal
>> HTTP: in this case, a Content-Length header would be appropriate
> 
> I interpret the "content" to not relate to the HTTP handshake, but
> belong to the WebSocket stream. To quote:
> 
> "I've moved some of the handshake to the WebSocket 
> _connection_, after the headers." (emphasis mine)
> 
> Besides, a GET request can't have a body, so it's pretty much intended
> to break. However, if you instead view the sequence as WS Upgrade ->
> client sent body -> server sent reply it is perfectly valid.
> 
>> Considering that we are already shipping products with
>> websocket implementations from the existing draft, can we
>> specify a transition to the new handshake in an appendix.
>>
>> Ie while the standard is under development connections without
>> websocket keys MAY be accepted, but implementation SHOULD warn
>> that support for such connections is deprecated.
> 
> Actually, it's not enough to just drop the keys. The header names
> changed too so you'd need to read WebSocket-Location instead of
> Sec-WebSocket-Location, for example. It's almost as if we're at a new
> "version" now.
>>
>> The text of 1.3, still kind of implies that the HTTP fields
>> must be ordered as per the spec.  Can we add a sentence to say
>> that header ordering may be different.
> 
> YMMV, but I don't see any such implication in the text.
> 
> Later on, the client handshake is explicitly asked to send the headers
> in a _random_ order (although _any_ order should do fine?) so there
> should be no confusion on that point.
>>
>> Also I'm not sure this sentence is really that clear:
>>
>> "Additional fields are used to select options in the WebSocket
>>   protocol.  The only option available in this version is the
>>   subprotocol selector, |Sec-WebSocket-Protocol|:"
>>
>> I thought we were going to allow arbitrary extra headers,
>> but that their interpretation was not defined by the ws spec
>> other than the optional Sec-WebSocket-Protocol.    We still
>> need to allow headers for cookies, authentication etc.
> 
> Yes. Client handshake step 15 explicitly adds those cookies. This part I
> guess is intended for things that can be modified directly using the
> API. The "arbitrary" extra headers permitted thus far are only things
> added by the browser implicitly. 
> 
> Vladimir
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi