[hybi] Final HTTP responses and WebSocket handshake

Yutaka_Takeda@PlayStation.Sony.Com Fri, 11 February 2011 01:35 UTC

Return-Path: <Yutaka_Takeda@PlayStation.Sony.Com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 8C8FD3A6971 for <hybi@core3.amsl.com>; Thu, 10 Feb 2011 17:35:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.084
X-Spam-Status: No, score=-6.084 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id W7DnC1LBynHu for <hybi@core3.amsl.com>; Thu, 10 Feb 2011 17:35:03 -0800 (PST)
Received: from paris.playstation.sony.com (nat.playstation.sony.com []) by core3.amsl.com (Postfix) with ESMTP id 1621A3A672F for <hybi@ietf.org>; Thu, 10 Feb 2011 17:35:02 -0800 (PST)
Received: from constantine.playstation.sony.com ([]) by paris.playstation.sony.com (Lotus Domino Release 8.5.1FP5) with ESMTP id 2011021017350857-442609 ; Thu, 10 Feb 2011 17:35:08 -0800
To: hybi@ietf.org
MIME-Version: 1.0
X-KeepSent: DD4ABE05:D6C65821-88257833:00822B82; type=4; flags=0; name=$KeepSent
X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006
Message-ID: <OFDD4ABE05.D6C65821-ON88257833.00822B82-88257834.0009316B@playstation.sony.com>
From: Yutaka_Takeda@PlayStation.Sony.Com
Date: Thu, 10 Feb 2011 17:40:24 -0800
X-MIMETrack: Serialize by Router on SCEA919ML04/SCEA(Release 8.5.1FP3|May 23, 2010) at 02/10/2011 05:35:08 PM, Serialize complete at 02/10/2011 05:35:08 PM, Itemize by SMTP Server on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 02/10/2011 05:35:08 PM, Serialize by Router on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 02/10/2011 05:35:17 PM, Serialize complete at 02/10/2011 05:35:17 PM
Content-Type: multipart/alternative; boundary="=_alternative 0009316988257834_="
Subject: [hybi] Final HTTP responses and WebSocket handshake
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Feb 2011 01:35:05 -0000

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 

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 
(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 
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.


Difference 1:
Upgrade TLS: Upgrading underlying transport layer to TLS, but not HTTP 
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.


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 
   - 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.
   - Existing HTTP implementation is likely designed to treat 101 as a 
     acceptance of the request wihere it tries to prepare for the final 
   - 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 
   ## It is desure a looser coupling from HTTP specific function - easy to 
add WebSocket to existing system (e.g. Apache)


- Why couldn't WebSocket handshake be done in a complete form of HTTP 
- 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!)


(1) Successful handshake

Client                             server
------                             ------
  |             GET                   |
  +---------------------------------->| << Connection: websocket is most 
  |                                   |    'Upgrade: websocket' isn't 
  |             200 OK                |
  +<----------------------------------| << Release HTTP sepcific resource,
  |                                   |    (it's natural as HTTP 
transaction is complete)
  |<========== WebSocket ============>|    then, mark the socket as 
                                           optionally read/write data on a 
new socket
                                           from a special 
                                           (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.

- Yutaka