Values of request headers, such as Accept-Language
, Accept-Encoding
, etc., have either implicitly or explicitly weighted values (en; q=0.8
for instance).
In the unlikely event that the parsed value of the complete field value yields ambiguous information, specifically if the ambiguity can be interpreted as either not acceptable (q=0
) or acceptable because of some non-zero quality value, for example:
Accept-Encoding: gzip; q=0.8, gzip; q=0
should this be interpreted as:
- not acceptable;
- acceptable;
- header is invalid;
or some other option, perhaps?
In RFC 7231, the general section 5.3.1 on quality values
The weight is normalized to a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred; a value of 0 means "not acceptable". If no "q" parameter is present, the default weight is 1.
and the Accept-Encoding
-specific section 5.3.4, subsection 3 and 4
If the representation's content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable unless it is accompanied by a qvalue of 0. (As defined in Section 5.3.1, a qvalue of 0 means "not acceptable".)
If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.
clearly say q=0
means "not acceptable" and that the highest non-zero qvalue is preferred, but they don't appear to discuss any possible ambiguity; probably because it is such an unlikely event.