ad Bills question in last paragraph: yes. I don't see any other possible
answer - the spec is already done and the EG cannot add/change any of
its behavior without doing a release (maintenance or full).
I would use different wording, but it more or less reflects current
state. (I just don't like the WebSocket endpoint / Servlet mapping
clashes, since it is really very different thing handled in different
specs - see WebSocket spec chapter 3.1.1. WebSocket spec does not
mention Servlet mapping at all, since it deals only with mapping withing
the app, as I already stated in the comment to referenced issue).
Regards,
Pavel
On 13/05/15 19:36, Bill Wigger wrote:
> 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.
>
>