- From: Shannon <shannon@arc.net.au>
- Date: Tue, 30 Sep 2008 14:59:19 +1000
Anne van Kesteren wrote: > What is the reason for doing literal comparison on the > websocket-origin and websocket-location HTTP headers? Access Control > for Cross-Site Requests is currently following this design for > access-control-allow-origin but sicking is complaining about so maybe > it should be URL-without-<path> comparison instead. (E.g., then > http://example.org and http://example.org:80 would be equivalent.) > > I think the temptation to standardise features like access control defeats the point of websockets. Since things like access control and sessions can be readily implemented via CGI interfaces it seems implied that the whole point of websockets is to provide "lightweight" services. If the service actually needs something like this then the author can perform the check post-handshake using any method they feel like. I don't really feel strongly one way or the other about this particular header but I'm concerned about the slippery-slope of complicating the HTTP handshake to the point where you might as well be using CGI. Maybe the standard should simply recommend sending the header but make no requirement about how it is parsed. That way the service itself can decide whether the check is even necessary and if so whether it should be strict or loose or regex-based without the client automatically hanging up the connection. Shannon
Received on Monday, 29 September 2008 21:59:19 UTC