- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 25 Nov 2011 16:39:34 +0100
- To: Harald Alvestrand <harald@alvestrand.no>
- CC: ietf-http-wg@w3.org
On 2011-11-25 00:15, Harald Alvestrand wrote: > Thanks for the datasets, Amos! > > Quick analysis of the 1742 different Accept-Language header: > > 156 multiple languages, none with q values > 247 single language with no q value > 43 all languages with q value > 1255 all languages but one with q value > 41 multiple languages without q value, some with q value > > I didn't check whether the values were always sorted; there were some > like this one: > > th-th,th;q=0.8,en-us;q=0.6,en-gb;q=0.4,en;q=0.2,x-ns1rW_REX3VNhu,x-ns2p1c0Nnym7b6 > > > where it certainly looks as if the accept-language header was used to > communicate something that isn't a standard language, but strictly > speaking, those rightmost values sort before #2 from the left, because > the default q value is 1.0. > > So there are 197 examples of headers whose interpretation according to > the standard might be affected by the proposed interpretation (or > integration of information from another specification). Could you by any chance check what UAs are sending these? I just tried FF8/IE9/Chrome15/Opera11, and they all send q values. (For Safari, I couldn't figure out how to get multiple languages into the header). > If practice out there is consistent with regard to this interpretation, > I think it is good to document it, so that we might reduce the chance of > future practice from diverging from current practice. I'm still unconvinced that there is a problem here: - we have no proof that the order is intentional and that it matters in these cases - there may be implementations written to what HTTP always said that treat values with same q value (or missing q value) as having the same preference, and a change to the spec would make those non-compliant - changing Accept-Language would make it inconsistent with the other Accept header fields (or do we want to change them all?) We *could* add a note that the interpretation is different here to the MIME variant, and point out that some senders may rely on it (if we really believe that). Best regards, Julian
Received on Friday, 25 November 2011 15:40:20 UTC