- From: Shannon <shannon@arc.net.au>
- Date: Thu, 24 Jul 2008 03:33:19 +1000
> > > > 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>
Received on Wednesday, 23 July 2008 10:33:19 UTC