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>wrote:
>> * Extension parameter ordering
>> http://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.
Mark