On 02/12/2014 09:01, Rémy Maucherat wrote: > 2014-12-02 9:46 GMT+01:00 Mark Thomas <ma...@apache.org>: > >> Assuming that this is coming from testing with the TCK, I'd like to see >> the results of challenging the affected tests (ideally with the >> discussion on the EG as a result of that challenge) before making any >> final decision on what the behaviour should be regarding the creation of >> a default origin header. >> > No, of course it is not a TCK test, I made it up myself. That was funny :) > So the assertion is that the TCK indeed seems to require a default origin > header. Websockets spec docs seems to indicate the origin header is part of > the standard, so that's probably why these tests were added: > http://en.wikipedia.org/wiki/WebSocket#WebSocket_protocol_handshake
Wikipedia does not define the WebSocket standard. That is defined in RFC 6455. To quote from RFC 6455: <quote> The |Origin| header field [RFC6454] is used to protect against unauthorized cross-origin use of a WebSocket server by scripts using the WebSocket API in a web browser. The server is informed of the script origin generating the WebSocket connection request. If the server does not wish to accept connections from this origin, it can choose to reject the connection by sending an appropriate HTTP error code. This header field is sent by browser clients; for non-browser clients, this header field may be sent if it makes sense in the context of those clients. </quote> Note "may be sent". The origin header is not mandatory so the TCK is wrong and needs to be challenged. I can't do that since I don't have access to the TCK. You have access to the TCK, you have to challenge it. If the TCK wants to test origin filtering then it simply needs to set the origin header in the TCK client code. > My opnion: it is more consistent and since the client does it, it doesn't > have a very large cost. Thus, I'm not very motivated to bring it to the EG, > but you can do it since the issue is simple to describe. My opinion is that the default value currently being provided is just plain wrong. The origin is meant to be "the script origin generating the WebSocket connection request" not the scheme, host and port of the WebSocket connection currently being made. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org