Hi Bill,
I can't find anything related in the spec, it seems to be undefined.
That implies each implementation can do pretty much whatever it wants.
I believe this is a consequence of loosely specified Servlet integration
(which was done intentionally if I recall correctly), which includes:
- Servlet 3.0 Scanning MUST BE used to discover endpoints in deployed
application (chapter 6.2)
- Programmatic deployment (ServerContainer registration in
ServletContext) (chapter 6.4)
- WebSocket root path relation to context path (chapter 6.5)
- HttpSession/Authentication (chapter 7.2)
, nothing related to potential conflicts with other Servlet/Container
path mappings (please correct me if I'm wrong).
The Reference implementations uses Servlet Upgrade APIs and registers
itself as servlet filter with mapping "/*" - if this would be written
in the spec itself, both questions can be answered by consulting Servlet
spec.
I don't think we should try to solve this issue in a way that checks for
duplicate mappings or tries to deal with that situation - servlet
already specifies ordering and mapping rules and we should not try to
modify it outside of "websocket app boundary". What we could do is to
allow apps to configure WebSocketServletFilter directly, so the ordering
will be known and defined and say that by default it will be handled by
ServletFilter registered as the last one, with (configurable?) mapping
(default value "/*"), but that would force all implementations to use
ServletFilter and that might not be something we want to do.
I guess it might be worth to file a new issue, or maybe "hijack" the one
you referenced:
https://java.net/jira/browse/SERVLET_SPEC-132.
Regards,
Pavel
On 12/05/15 15:04, Bill Wigger wrote:
> I want to clarify a point about Websocket Endpoint mappings and the
> Websocket spec.
>
> Case I:
> I have a websocket endpoint that is defined
> as /mydirectory/myendpoint.html
> and I also have a file defined in my WAR at /mydirectory/myendpoint.html
>
> Case II:
> Wildcards. I have a websocket endpoint defined
> as /mydirectory/{any-string}, and I also have a serlvet mapped
> to /mydirectory/myServlet
>
> Possible outcomes of these two cases:
>
> 1. Not a valid configuration that may result in errors for one or both of
> the mapptings, depending on the websocket implementation.
> or
> 2. the appserver/websocket code should send the request to the websocket
> code if and only if the upgrade header value is "websocket",
> else it will process the URI without going to the websocket code, using any
> applicable URI-without-websocket-upgrade-mapping.
> So, logically, there are two exclusive mappings: "URIs with websocket
> upgrade headers", and "URIs without websocket upgrade headers"
>
> Answer 1 seems like the right answer, in that you normally don't have
> identical URIs map to two different resources.
>
> This would be similar to the servlet question posted here:
> https://java.net/jira/browse/SERVLET_SPEC-132?jql=project%20%3D%20SERVLET_SPEC
>
> regards,
> Bill Wigger.