hi Pavel,
I agree with your comments about the loosely specified Servlet integration
and the suggestion not to see overlapping mappings as an error but rather a
question of adding transparency and letting developers decide.
I do think there are good reasons for the loose integration but there is no
reason for the end result to feel as segregated from a developer's
perspective. For the developer it's still one web application with
HTTP/REST and WebSocket functionality. Currently it feels more like the two
are sharing a server in loosely specified ways. It's not surprising then
that overlaps can occur unintentionally. Hence defining how a WebSocket
implementation fits into the Servlet mappings would be very useful.
The issue however goes farther. Even with more transparent mappings for
HTTP an application must use a Servlet while for WebSocket requests it must
leave it to the WebSocket implementation's Filter or Servlet. This makes it
harder to deal with something like HTTP fallbacks than it needs to be.
Fallbacks are an essential part of using WebSockets today, yet there have
been no discussions to my knowledge among the expert group.
I think WebSocket implementations should expose an upgrade API in addition
to providing a filter in which case a single application Servlet can decide
how to deal with all URLs under its mappings. I realize this would be an
alternative to using WebSocket annotations which are a key part of the spec
but there is already a programmatic Endpoint API. It makes sense to provide
a programmatic upgrade. That would add yet another level of transparency
and completely eliminate questions about overlapping mappings.
Regards,
Rossen
On Wed, May 13, 2015 at 3:26 AM, Pavel Bucek <pavel.bucek_at_oracle.com> wrote:
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__java.net_jira_browse_SERVLET-5FSPEC-2D132&d=AwIC-g&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=uDvnCNVzrsrMA2tdWMzThXynKGEaHizfljr_KGyAMhg&m=DQ9U4T_XXlfxazzvyuP3Fmoh0t3HC4o-s8fwXgmdpS0&s=gwZEe0jPTLMenK1Q7YRWwaPwxvIhcsOOx3ntot_1ANo&e=
> .
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__java.net_jira_browse_SERVLET-5FSPEC-2D132-3Fjql-3Dproject-2520-253D-2520SERVLET-5FSPEC&d=AwIC-g&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=uDvnCNVzrsrMA2tdWMzThXynKGEaHizfljr_KGyAMhg&m=DQ9U4T_XXlfxazzvyuP3Fmoh0t3HC4o-s8fwXgmdpS0&s=XDMmahF88fr7OowsUxDjDNzylNQauJ8auElCYPaaxe8&e=
>> regards,
>> Bill Wigger.
>>
>
>