2014-12-02 12:12 GMT+03:00 Mark Thomas <ma...@apache.org>: > 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.
Just some thoughts (not knowing what TCK does here): Per WebSocket RFC the origin header is mandatory for browser clients and not mandatory for non-browser clients. If one implements a web application then it is reasonable to expect that client is a web browser. If Origin is unknown, it can be written as "null" (a string of 4 characters) https://tools.ietf.org/html/rfc6454#section-6.1 Origin RFC 7.3.: [quote] Whenever a user agent issues an HTTP request from a "privacy- sensitive" context, the user agent MUST send the value "null" in the Origin header field. [/quote] If one runs a command-line websocket client instead of a browser, can it be configured to send a specific value of Origin header? (Via command line or via a system property) >> 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. Agreed. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
