RE: ACTION: The order of HTTP Headers

"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
not.

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.

Jo

> -----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
not
> > sure that this makes it either easier or harder select values ...
> >
> > e.g. //primaryDoc//HTTPResponse[last()]/header[@name="charlie"] does
not
> > 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