On 28/11/2014 20:33, r...@apache.org wrote: > Author: remm > Date: Fri Nov 28 20:33:20 2014 > New Revision: 1642360 > > URL: http://svn.apache.org/r1642360 > Log: > - Use the extensions specified by the configuration (and ignore if there are > no associated transformations).
I can see how this would make sense if there was a way for the application to configure its own extensions but there isn't. At the moment extensions have to be hard-coded into the container and there is no requirement to support any extension. If a server endpoint requests an unsupported extension then shouldn't that trigger some sort of error? > - Add an origin header on the client. There are multiple issues with this part of the commit: - the target is added rather than the origin - the full URI is used rather than scheme, host and optional port See http://tools.ietf.org/html/rfc6454#section-7 > - Add path params as params too. I don't see that discussed anywhere in the WebSocket spec. I went back through the EG discussions and the thread that I think led up to this [1],[2] was very clear that this was the query parameters and did not include the path parameters [1] https://java.net/projects/websocket-spec/lists/jsr356-experts/archive/2012-07/message/2 [2] http://markmail.org/message/qqwqcyg4npxv3bks > - Use the case insensitive map for all headers. Makes sense. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
