W3C home > Mailing lists > Public > public-mobileok-checker@w3.org > May 2007

RE: ACTION: The order of HTTP Headers

From: Jo Rabin <jrabin@mtld.mobi>
Date: Wed, 23 May 2007 16:24:06 +0100
Message-ID: <C8FFD98530207F40BD8D2CAD608B50B4335E7E@mtldsvr01.DotMobi.local>
To: "Sean Owen" <srowen@google.com>
Cc: <public-mobileok-checker@w3.org>

"I don't disagree" (TM) however in the context of normalizing order one
would also have to consider ordering of elements within the header field
and the order of parameters within elements.

For example: 

Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
        text/html;level=2;q=0.4, */*;q=0.5

the elements could be in any other order and be just as sweet. Whether
this is true in general I don't know as I have only got as far as 'c' in
the header name list.

This is not true of the parameters though, if I have understood the
spec, in that the parameter(s) (by which they mean the media range
parameters specified somewhere else) precede the q= which precedes any
accept-extension. Whatever that is (Other than an x=y construct).

       Accept         = "Accept" ":"
                        #( media-range [ accept-params ] )

       media-range    = ( "*/*"
                        | ( type "/" "*" )
                        | ( type "/" subtype )
                        ) *( ";" parameter )
       accept-params  = ";" "q" "=" qvalue *( accept-extension )
       accept-extension = ";" token [ "=" ( token | quoted-string ) ]

So, ref normalization of order, I think we can safely sort headers (as
long as we preserve the original order of headers with the same name
normalized for case).

I don't know, but I expect we can sort elements - though whether this
should be lexical ordering or preference ordering followed by lexical
ordering, is probably an exercise for the student. And I am worried that
RFC 2616 says that the ordering of headers of the same name _is_
significant because of wishing to be able to reconstruct a single header
of that name, so that throws this assumption into doubt.

In general I don't think we can order parameters, though in many cases
the order is not significant.

All of which leads me to conclude that diffing results documents may not
be a reliable way to determine whether the semantics are the same or

However, it also leads me to ask whether a moki document will actually
form part of that comparison? Surely we will be comparing the results
format? If that is RDF then I suppose we will have to use an RDF tool to
make the comparison?

Now back to the Content-Encoding header.


> -----Original Message-----
> From: Sean Owen [mailto:srowen@google.com]
> Sent: 23 May 2007 15:24
> To: Jo Rabin
> Cc: public-mobileok-checker@w3.org
> Subject: Re: ACTION: The order of HTTP Headers
> On 5/23/07, Jo Rabin <jrabin@mtld.mobi> wrote:
> > For moki, I would prefer to maintain the ordering as received. I'm
> > sure that this makes it either easier or harder select values ...
> >
> > e.g. //primaryDoc//HTTPResponse[last()]/header[@name="charlie"] does
> > depend on the ordering ...
> No but testing does. Now you can't merely diff two documents and tell
> whether they are the same, because header ordering may cause spurious
> differences. It's not impossible to rewrite the test code to parse all
> this out and order it and compare, but, it's a fairly big jump in
> complexity for no apparent benefit -- we do have the original response
> recorded anyway, with ordering intact. We're normalizing away notably
> more than the order already so I'm not seeing much of a downside to
> ordering.
Received on Wednesday, 23 May 2007 15:24:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:18 UTC