Re: [hybi] Final HTTP responses and WebSocket handshake

[[e-mail]]

Hi,

> Does any have any thoughts on my other concern? 
> > o Relatively more complexi in adding WebSocket to the existing 
> implemtation of HTTP server. 
> ...

Please let me take back the above comments.

What HTTP offers with Upgrade header and 101 response is not just
for switching underlying protocol but also including HTTP layaer 
itself. Therefore, what I was pointing out wan inherent in HTTP 
protocol, not in WebSocket. Under WebSocket's requirements, 
REQ.8 and REQ.9, I agree that the current approach with Upgrade
header/101 is the best possible way for WebSocket to reuse 
existing HTTP features.


- Yutaka


[e-mail] wrote on 02/11/2011 03:26:02 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.
> 
> 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
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi