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