<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<span style="white-space: pre;">>> <br>
>> 3.) If the resulting absolute URL has a <port>
component, then let<br>
>> port be that component's value; otherwise, if secure is false,
let<br>
>> port be 81, otherwise let port be 815.<br>
>> </span><br>
<br>
I found this in rfc2817 section 1:<br>
<br>
The historical practice of deploying HTTP over SSL3 [3] has<br>
distinguished the combination from HTTP alone by a unique URI scheme<br>
and the TCP port number. The scheme 'http' meant the HTTP protocol<br>
alone on port 80, while 'https' meant the HTTP protocol over SSL on<br>
port 443. Parallel well-known port numbers have similarly been<br>
requested -- and in some cases, granted -- to distinguish between<br>
secured and unsecured use of other application protocols (e.g.<br>
snews, ftps). This approach effectively halves the number of<br>
available well known ports.<br>
<br>
At the Washington DC IETF meeting in December 1997, the Applications<br>
Area Directors and the IESG reaffirmed that the practice of issuing<br>
parallel "secure" port numbers should be deprecated. The HTTP/1.1<br>
Upgrade mechanism can apply Transport Layer Security [6] to an open<br>
HTTP connection.<br>
<br>
<br>
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:<br>
<br>
3.2 Mandatory Upgrade<br>
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).<br>
<br>
OPTIONS * HTTP/1.1<br>
Host: example.bank.com<br>
Upgrade: TLS/1.0<br>
Connection: Upgrade<br>
<br>
<br>
Nor does the WebSocket server supply a valid response:<br>
<br>
3.3 Server Acceptance of Upgrade Request<br>
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:<br>
<br>
HTTP/1.1 101 Switching Protocols<br>
Upgrade: TLS/1.0, HTTP/1.1<br>
Connection: Upgrade<br>
<br>
Obviously this is referring to TLS however WebSockets is also a
protocol switch and should therefore follow the same rules.<br>
<br>
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:<br>
<br>
* Validating and parsing HTTP headers (that doesn't mean they are all
understood or implemented, simply collected into a native
structure/object/array)<br>
* Handling (or simply pattern-matching) the Version, Upgrade and
Connection headers<br>
* Adding a Content-Length header before each message sent to the client
and/or "chunk encoding" variable-length messages<br>
* Sending and respecting the "connection close" message<br>
* Sending "not implemented", "not authorised" and error status messages
as needed.<br>
<br>
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.<br>
<br>
Shannon<br>
<br>
<br>
</body>
</html>