Re: [hybi] Final HTTP responses and WebSocket handshake

[[e-mail]]

> This is not aligned with the WG consensus for HTTP compatibility (up
> until the websocket handshake is complete) declared some time back 
> by the chairs.
> The websocket handshake is not complete until a 101 comes back. So 
> anything before than (including other response codes, 
> reauthentication, etc) are not anything the websockets draft can say
> anything about. It's just compatible HTTP as usual.

Ah, I see. So, HTTP transaction can be iterated until 101 comes in.
I may have over-reacted to the text:

> In Section 1.3: 
> "Any status code other than 101 must be treated as a failure and the 
websocket connection aborted." 

I agree, this needs to be fixed. In fact, any status code other than 101 
MUST be handled
in a way that conforms with HTTP. (which is out of scope of this 
document).

Does any have any thoughts on my other concern?

> o Relatively more complexi in adding WebSocket to the existing 
implemtation of HTTP server. 
>   Reasons: 
>    - Existing HTTP implementation is likely designed to treat 101 as a 
indefinitive 
>      acceptance of the request wihere it tries to prepare for the final 
response... 
>    - Where, on receipt of a final response, such as 200 OK, the 
likelihood of exisiting implementaion 
>      would prepare for releasing HTTP protocol specific resources in 
memory to terminate 
>      the transaction. 
>   
>    ## This impact on adoption of WebSocket procol by existing HTTP 
servers. 
>    ## It is desired a loose coupling with HTTP specific function - easy 
to add WebSocket to existing system (e.g. Apache) 

Say, we try to implement WebSocket in Apache, or via Apache module. Since 
actual WebSocket
connection resides in the middle of the HTTP GET transaction, the process 
or thread that is
processing the transaction has taken up its sufficiently large resources 
for handling any type of
HTTP transaction, and most of which will no longer be necessary once the 
WS handshake is 
complete. Consequently, such implementation in Apache will be very 
expensive and probably
not practical for large scale deployment.

If we could complete the WS handshake in a complete HTTP transaction 
(successful 
handshake completes on receipt of 200 OK, for example), then this will 
have a completely
different view. Coming back to the example with Apache, the resources for 
the transaction
(process/thread/mempool/context, etc.) can be released completely. What 
needs to done
is in its socket management code be modified to leave the socket (at this 
point being 
'websocket' open and transfer it to an internal or external facility that 
can efficiently handle
persistent/bidirectional communication.

More specifically, the Connection header is about what to do with the 
underlying connection
*after* the current transaction is complete. So, we only needed to define 
a new value to
the Connection header like:

    Connection: websocket

(# of course, 'Sec-Websocket-xxx' headers are still necessary, 'Upgrade: 
websocket' can be eliminated.)

This can be reported to the socket management layer to tell, "the socket 
is going to be used
as WebSocket". (don't close and don't use it for subsequent HTTP 
transactions.)
Please notice that, there's no HTTP layer involved at this point!

This is clearly MUCH less work than tackling situation where transaction 
is left open upon 
101 response, and yet MUCH cleaner solution for introducing WebSocket 
feature into
existing HTTP servers.


Any thoughs?

--
Yutaka Takeda - US R&D Sony Computer Entertainment, Inc.
Office: 650 655 7484   Fax: [phone]


[e-mail] wrote on 02/10/2011 05:57:51 PM:

> This is not aligned with the WG consensus for HTTP compatibility (up
> until the websocket handshake is complete) declared some time back 
> by the chairs.
> The websocket handshake is not complete until a 101 comes back. So 
> anything before than (including other response codes, 
> reauthentication, etc) are not anything the websockets draft can say
> anything about. It's just compatible HTTP as usual.
> 
> So this is a bug in the spec, hopefully to get taken care of in 06.
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf 
Of
> > Greg Wilkins
> > Sent: 10 February, 2011 17:49
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: Re: [hybi] Final HTTP responses and WebSocket handshake
> > 
> > On 11 February 2011 12:40,  <[e-mail]> 
wrote:
> > >
> > > o  Cannot get full benefit out of HTTP protocol during the handshake
> > > as it does not expect a final response:
> > >   For example:
> > >    - Can not redirect WebSocket handshake to another server (for 
load
> > > balancing, fail-over, etc.)
> > >    - Can not perform user authentication (Basic, Digest, etc.) 
during
> > > the handshake.
> > >    - Similarly, 407 authentication cannot be forced by the server.
> > 
> > +1
> > 
> > In the ancient history of this list, I have long argued for exactly 
this.
> > 
> > Apparently there are some security concerns about browser redirection, 
which
> > I never really understood... and even if there are, I don't see 
> the reason that the
> > protocol should deny the use of non 101 handshake responses to all
> clients.  I
> > think the protocol should allow arbitrary response codes (because it 
can't
> > actually prevent them being sent by non WS servers anyway), and then
> > individual clients can decide which responses they will handle (which 
may be
> > better discuss in the appropriate HTML 5 forums regarding the specific
> > websocket API).
> > 
> > cheers
> > _______________________________________________
> > hybi mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/hybi
> 
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi