[jsr356-experts] Re: [jsr356-users] Re: Pot Pourri of issues from Public Draft

From: Justin Lee <jlee_at_antwerkz.com>
Date: Fri, 25 Jan 2013 22:40:29 -0500

yes, i was thinking ordering of headers not the values within a given
header. so this works for me.

On Fri, Jan 25, 2013 at 6:23 PM, Danny Coward <danny.coward_at_oracle.com>wrote:

> On 1/21/13 4:24 AM, Mark Thomas wrote:
> On 19/01/2013 16:39, Justin Lee wrote:
> On Fri, Jan 18, 2013 at 8:23 PM, Danny Coward <danny.coward_at_oracle.com> <danny.coward_at_oracle.com>wrote:
> * Extension parameter orderinghttp://java.net/jira/browse/WEBSOCKET_SPEC-105
> Currently the API models extension parameters as Map<String, String>, yet
> the parameters have an order in the http headers. While this order doesn't
> have a meaning in the websocket protocol specification, both the MUX and
> Compression extensions attach semantic meaning to specific parameters, so
> it is perfectly possible that some new extension might attach semantic
> meaning to their order. So, I think our API needs to preserve them. I
> suggest we model extension parameters as List<Parameter> where Parameter is
> a member type of Extension, and contains the parameter name and value as
> Strings.
> I don't think header ordering matters anywhere in any common protocols. I
> don't think we should bend over backwards making this a requirement outside
> of something forcing us to. I'd be really, really surprised if any
> extensions make it out of specification with that requirement. Even HTTP
> only specifies the first 2ish headings and that's merely to aid in protocol
> identification. I'm a -1 on this one.
> Since HTTP does define an order for parameter values within an HTTP
> header then I think it is reasonable that our API retains that order
> unless there is a good reason for not doing so.
> Yes I agree with Mark on this one. Ordering of the extensions themselves
> is semantically meaningful within the websocket spec, and while the
> ordering of a particular extensions parameters don't seem to be being used
> by any of the existing extensions, we just don't know if they will in the
> future.
> I'd rather we not be the spec that gets in the way of that !
> - Danny
> Mark
> --
> <http://www.oracle.com> * Danny Coward *
> Java EE
> Oracle Corporation

You can find me on the net at:
http://antwerkz.com             http://antwerkz.com/+
http://antwerkz.com/twitter   http://antwerkz.com/github