jsr356-experts@websocket-spec.java.net

[jsr356-experts] Re: getParameterMap and 1.1 TCK

From: Joakim Erdfelt <joakim_at_intalio.com>
Date: Thu, 29 Jan 2015 08:48:21 -0700

Update from Jetty ...

We treat HandshakeRequest.getParameterMap() as the javadoc says, "the
request parameters associated with the request".
in other words, identical to ServletRequest.getParameterMap().

The uri-template parts, that result in @PathParam references are "path
parameters".
Jetty does not return path parameter values in the
HandshakeRequest.getParameterMap() call.


--
Joakim Erdfelt <joakim_at_intalio.com>
webtide.com <http://www.webtide.com/> - intalio.com/jetty
Expert advice, services and support from from the Jetty & CometD experts
eclipse.org/jetty - cometd.org
On Thu, Jan 29, 2015 at 7:54 AM, Mark Thomas <mark_at_homeinbox.net> wrote:
> On 29/01/2015 13:42, Bill Wigger wrote:
> > In the WebSocket javadoc for HandshakeRequest.getParameterMap it says
> > that it returns:
> > Map<String,List<String>>
> > Return the request parameters associated with the request.
> >
> > That seems to mirror what is written in the javadoc for
> > javax.servlet.ServletRequest.getParameterMap
> > where it says: Returns a java.util.Map of the parameters of this request
> >
> > So for this request: ws://whatever:8080/myWebSocketApp/123?abc=345
> >
> > one might expect that key:abc - value:345 would be in the parameter map
> > return from HandshakeRequest.getParameterMap
>
> That would be my expectation.
>
> > But, the TCK seems to enforce that both of the following be in the
> > parameter map
> > key:abc - value:345   and
> > key:{user-path-param-name} - value:123
> >
> > That seems to be mixing two types of paramters (websocket path params,
> > and http request query string parameters) into one
> > map, and seems to expand what is meant in the javadoc ("websocket path
> > parameters", rather than "servlet request parameters").
> >
> > Seems to me the 1.1 TCK is wrong here, no?
>
> The behaviour you say the TCK is expecting (I don't have access to it)
> is sufficiently far from what I think that most folks would expect that
> I'd expect it to be specifically mentioned in the spec and/or Javadoc. I
> don't see it. Neither do I recall any such discussions in the EG.
>
> I agree that the TCK is making an invalid assumption here.
>
> Mark
>
>