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
