[whatwg] Web Sockets

[Shannon]

> >
> > 3.) If the resulting absolute URL has a <port> component, then let
> > port be that component's value; otherwise, if secure is false, let
> > port be 81, otherwise let port be 815.
> >

I found this in rfc2817 section 1:

   The historical practice of deploying HTTP over SSL3 [3] has
   distinguished the combination from HTTP alone by a unique URI scheme
   and the TCP port number. The scheme 'http' meant the HTTP protocol
   alone on port 80, while 'https' meant the HTTP protocol over SSL on
   port 443.  Parallel well-known port numbers have similarly been
   requested -- and in some cases, granted -- to distinguish between
   secured and unsecured use of other application protocols (e.g.
   snews, ftps). This approach effectively halves the number of
   available well known ports.

   At the Washington DC IETF meeting in December 1997, the Applications
   Area Directors and the IESG reaffirmed that the practice of issuing
   parallel "secure" port numbers should be deprecated. The HTTP/1.1
   Upgrade mechanism can apply Transport Layer Security [6] to an open
   HTTP connection.


I believe we should rule out both new ports in favour of upgrading a 
port 80 connection to a WebSocket; however according to the same 
document the WebSockets proposal does not follow the expected 
client-side behaviour for doing so:

3.2 Mandatory Upgrade
If an unsecured response would be unacceptable, a client MUST send an 
OPTIONS request first to complete the switch to TLS/1.0 (if possible).

       OPTIONS * HTTP/1.1
       Host: example.bank.com
       Upgrade: TLS/1.0
       Connection: Upgrade


Nor does the WebSocket server supply a valid response:

3.3 Server Acceptance of Upgrade Request
As specified in HTTP/1.1 [1], if the server is prepared to initiate the 
TLS handshake, it MUST send the intermediate "101 Switching Protocol" 
and MUST include an Upgrade response header specifying the tokens of the 
protocol stack it is switching to:

       HTTP/1.1 101 Switching Protocols
       Upgrade: TLS/1.0, HTTP/1.1
       Connection: Upgrade

Obviously this is referring to TLS however WebSockets is also a protocol 
switch and should therefore follow the same rules.

I understand the reluctance to use a true HTTP handshake (hence the 
ws:// scheme and alternate ports) however I think the claims of added 
complexity on the server end are exaggerated (I say this as somebody who 
has written a basic standalone webserver). It seems to me we're only 
looking at required support for:

* Validating and parsing HTTP headers (that doesn't mean they are all 
understood or implemented, simply collected into a native 
structure/object/array)
* Handling (or simply pattern-matching) the Version, Upgrade and 
Connection headers
* Adding a Content-Length header before each message sent to the client 
and/or "chunk encoding" variable-length messages
* Sending and respecting the "connection close" message
* Sending "not implemented", "not authorised" and error status messages 
as needed.

Currently WebSockets requires practically all of these features as well, 
except that it implements them in non-standard fashion - effectively 
making asyncronous delivery via existing infrastructure (ie: CGI) a 
potentially more difficult and error-prone affair. In fact as it stands 
I would say the current proposal rules out both CGI and proxy support 
entirely since it cannot handle the addition of otherwise valid HTTP 
headers (such as Expires, X-Forwarded-For or Date) in the first 85 bytes.

Shannon


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080724/caba072f/attachment.htm>