[hybi] Final HTTP responses and WebSocket handshake

[[e-mail]]

After a careful reading of -05, the following text got me thinking of 
someting important, and
I would like to point that out here, and I would like to hear your 
thoughts.

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


CURRENT STATUS (from what I understand):

I realized, the WebSocket handshake is done in the first half of HTTP GET 
transaction
(GET -> 101) according to the current specification, and it never expects 
final response codes
(2xx, 3xx, 4xx, 5xx) processed as a part of handshake. The 'websocket' is 
resides in the 
second half of the GET transaction, and as WebSocket is a 
persistent/bidirectional 
connection, it will never see a final reponse to the GET request. 
WebSocket handshake has
clearly been modeled after RFC 2817 (HTTP Upgrade to TLS) and it could be 
perceived as 
'similar' to what WebSocket is trying to achieve. However, I see a 
fundamental difference
in between RFC 2817 and WebSocket as following.


ESSENTIAL DIFFERENCE FROM RFC 2817 ("Upgrade TLS"):

Difference 1:
Upgrade TLS: Upgrading underlying transport layer to TLS, but not HTTP 
layer
WebSocket: Switching HTTP to WebSocket, but not transport layer

Difference 2:
Upgrade TLS: It eventually receives final respoonse to complete 
transaction. (No compomise in HTTP functionality)
WebSocket: The transaction never ends in terms of HTTP transaction.

With Upgrade TLS, the provisional response was necessary because 
subsequent response 
needs to be conveyed over the TLS, while WebSocket shouldn't have had to 
use this 'Upgrade'
mechanism to begin with.


POSSIBLE CONSEQUENCES:

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.

   ## These impact on deployment of WebSocket services.

o Relatively more complexity 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 desure a looser coupling from HTTP specific function - easy to 
add WebSocket to existing system (e.g. Apache)


MY THOUGHTS/DOUBTS

- Why couldn't WebSocket handshake be done in a complete form of HTTP 
transaction?
- Any specific reasons for ruling out the usefulness of final responses 
for the handshake?
- Is the current spec really acceptable from deployment perspectives??
- Has 'non-browser' use of WebSocket truely been considered?
  (non-browser app may not have priori knowlege of final desitnation or 
any requirement of server/proxy authentication)
- Finally, I must be completely wrong about the current spec. (my hope! 
please give me a hint!)


DESIRED SEQUENCE EXAMPLES AS I SEE:

(1) Successful handshake

Client                             server
------                             ------
  |             GET                   |
  +---------------------------------->| << Connection: websocket is most 
important
  |                                   |    'Upgrade: websocket' isn't 
necessary.
  |             200 OK                |
  +<----------------------------------| << Release HTTP sepcific resource,
  |                                   |    (it's natural as HTTP 
transaction is complete)
  |<========== WebSocket ============>|    then, mark the socket as 
'websocket'
                                           optionally read/write data on a 
new socket
                                           from a special 
process/thread...
                                           (enables loose coupling from 
HTTP server core)
(2) 307 Temporary Redirect

Client                             server1  server2
------                             -------  -------
  |             GET                   |        |
  +---------------------------------->|        | \
  |                                   |        |  : Handshake == complete 
HTTP transaction
  |       307 Temporary Redirect      |        |  :
  +<----------------------------------|        | /
  |                                   |        |
  |             GET [1]               |        |
  +------------------------------------------->| \
  |                                   |        |  : Handshake == complete 
HTTP transaction
  |             200 OK                |        |  :
  +<-------------------------------------------| /
  |                                   |        |
  |<================ WebSocket ===============>|
  |                                   |        |


# I just thought I might as well speak out my concern. I am aware it is 
pretty late for this level of dicussion at this point, however...

Awaiting any of your response/objection/denials.

Best.
- Yutaka