Date: Wed, 13 May 2015 13:36:57 -0400
Allowing the user app to choose to do WebSockets may be a solution to
consider, something along the lines of exposing a WebSocket UpgradeHander
to the user app that the user could then call HttpServletRequest.upgrade
(...) with, not saying that is what should be done, but just throwing it
out there as an example of the direction we might want to take.
I don't think we should mandate the use of filters with WebSockets, filters
can have drawbacks (ordering, preventing other filters from running) and
there is nothing inherent in the websocket spec that needs filters. I'm
not saying implementations can not use filters, I just don't see a strong
enough reason to mandate the use of them.
So, I guess for now we are saying that it is up to an implementation about
how to handle WebSocket Endpoint and Serlvet mapping clashes, and that this
is an issue that needs to be resolved going forward, but isn't resolved
with the current set of WebSocket and Servlet Specs and APIs ?
regards,
Bill
From: Rossen Stoyanchev <rstoyanchev_at_pivotal.io>
To: jsr356-experts <jsr356-experts_at_websocket-spec.java.net>
Date: 05/13/2015 10:42 AM
Subject: [jsr356-users] [jsr356-experts] Re: Re: overlapping websocket
URI mappings
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.
(image/gif attachment: graycol.gif)