3

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:

  1. not acceptable;
  2. acceptable;
  3. 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

  1. 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".)

  2. 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.

Community
  • 1
  • 1
Decent Dabbler
  • 22,532
  • 8
  • 74
  • 106

1 Answers1

2
  1. 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".)

  2. If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.

The header Accept-Encoding: gzip; q=0.8, gzip; q=0 has a single content-coding gzip which is repeated with different qvalues.

  • First, it is accompanied by the qvalue 0.8 which is "acceptable"
  • Second, it is accompanied by the qvalue 0 which is "not-acceptable".

As I read the quoted rules:

  1. Check to see if a content-coding is accompanied by a qvalue of zero; if so, it is "not acceptable";
  2. Otherwise, take the maximum qvalue weight of all the duplicates.

So my interpretation would be that the two lines below are equivalent:

Accept-Encoding: gzip, gzip;q=0.001, compress;q=0.1, compress;q=0, *;q=0.2, *;q=0.1
Accept-Encoding: gzip;q=1, compress;q=0, *;q=0.2

and for your example, the following two lines are the same:

Accept-Encoding: gzip; q=0.8, gzip; q=0
Accept-Encoding: gzip;q=0
MT0
  • 143,790
  • 11
  • 59
  • 117
  • This is a compelling argument, but I think there are two problems: - It relies on changing the definition of "content-coding" between the two steps. In the first, “the” content-coding is said to have “a” quality value. In the second, for this interpretation, we must consider content coding to refer not to a unique token but rather to individual occurrences of the token. - It applies only to accept-encoding. None of the other negotiation headers have rules that permit this interpretation. I’m pretty sure it’s just unspecified behavior, though this is a good choice for how to handle it. – Semicolon Apr 28 '18 at 16:18