[whatwg] Web Sockets
shannon at arc.net.au
Wed Jul 23 10:33:19 PDT 2008
> > 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  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  to an open
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
Nor does the WebSocket server supply a valid response:
3.3 Server Acceptance of Upgrade Request
As specified in HTTP/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
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
* Handling (or simply pattern-matching) the Version, Upgrade and
* 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg