On 12/05/2015 19:24, Bill Wigger wrote:
> If the idea is that the websocket code fails the request somehow, then
> the appserver tries another non-websocket endpoint that may be sharing
> all or part of the /mydirectory/* mapping, then that seems like it
> should be defined somewhere, most likely in the servlet spec, since it
> is the appserver/servlet code that is receiving the failure and then
> trying to find a new mapping. But I don't see that anywhere in the
> Servlet spec. What is the appropriate way for the websocket code to
> signal the appserver, "this request wasn't really for me, but I'm not
> rejecting it back to the user" ?
>
> If we add another protocol to the equation, which also has mapped
> endpoints to /mydirectory/*, then how does the appserver handle that?
> How does it decide who gets first shot at the request?
The short answer is since it is impossible to implement WebSocket on top
of the Servlet spec then the app server handles it however it likes.
The longer answer is that, assuming the WebSocket implementation uses
the Servlet API where it makes sense to do so, the HTTP upgrade can be
triggered from a Filter or a Servlet. Since a request can have multiple
filters mapped but only one Servlet it is likely that each of these
protocols will have registered a Filter. It then simply boils down to
the order configured for the Filters. If a protocol wants to handle the
request, it does so. If it doesn't, it passes it down the chain.
The other option is that the app does it all itself and uses the
programmatic API to start WebSocket processing if it wants to. It is
then free to choose which protocol to use for a given request to a given
URI.
> So, I guess my main question comes down to, between the WebSocket and
> Servlet spec, how does one deal with multiple mappings of one URI to
> mulitple endpoints?
In Servlet the "WebSocket Filter" is mapped to /*.
The "WebSocket Filter" then uses the mappings for the registered
endpoints to determine if it processes the request, rejects the request
or passes it on.
> It seems this information is missing from the
> specs, so then what would be the appropriate algorithm/APIs for handling
> this situation, and which spec should include it?
If it is anywhere, I think it has to be in WebSocket.
> One of my concerns is
> that different implementations are going to make up their own rules here.
Something along the lines of "When running in a Servlet container, if a
valid WebSocket HTTP upgrade is received with a URI that does not match
a registered endpoint then it MUST be passed to the Servlet container
for processing." should clarify this.
We could be more prescriptive (e.g. specify the use of a Filter) but I
don't (currently) see a need to tie implementers hands that way at the
moment.
Cheers,
Mark
> regards,
> Bill
>
> Inactive hide details for Mark Thomas ---05/12/2015 10:52:49 AM---On
> 12/05/2015 14:04, Bill Wigger wrote: > I want to clarify aMark Thomas
> ---05/12/2015 10:52:49 AM---On 12/05/2015 14:04, Bill Wigger wrote: > I
> want to clarify a point about Websocket Endpoint mapping
>
> From: Mark Thomas <mark_at_homeinbox.net>
> To: jsr356-experts_at_websocket-spec.java.net
> Date: 05/12/2015 10:52 AM
> Subject: [jsr356-experts] Re: overlapping websocket URI mappings
>
> ------------------------------------------------------------------------
>
>
>
> On 12/05/2015 14: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.
>
> I disagree. Answer 2 is often used when the client doesn't know how
> capable the server (or the proxy between it and the server) is so, for
> example, it tries WebSocket and then falls back to HTTP.
>
> Mark
>
>>
>> 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.
>>
>
>