Subject: Is “fr, en; q=0.3” a valid Accept-Language value?

From: Samuel Williams <[email-masked]>
Date: Wed, 19 Oct 2016 13:31:40 +1300

According to the RFC, it's okay to have *LWS between words and
separators. However, if you look at the specific ABNF for matching the
Accept-Language field, it doesn't allow for whitespace around the ;
character.

Here is the exact LWS specification:

implied *LWS: The grammar described by this specification is
word-based. Except where noted otherwise, linear white space (LWS) can
be included between any two adjacent words (token or quoted-string),
and between adjacent words and separators, without changing the
interpretation of a field. At least one delimiter (LWS and/or
separators) MUST exist between any two tokens (for the definition of
"token" below), since they would otherwise be interpreted as a single
token.

Here is the ABNF grammar:

   Accept-Language = "Accept-Language" ":"
                     1#( language-range [ ";" "q" "=" qvalue ] )
   language-range  = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )

Any advice would be appreciated. Thanks

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Oct 2016 08:32:12 +0200

> Any advice would be appreciated. Thanks

a) Look at the current spec, not RFC 2616.

b) Over there you will find:

>   weight = OWS ";" OWS "q=" qvalue
>   qvalue = ( "0" [ "." 0*3DIGIT ] )
>          / ( "1" [ "." 0*3("0") ] )

<https://greenbytes.de/tech/webdav/rfc7231.html#quality.values>

Best regards, Julian

---

From: Samuel Williams <[email-masked]>
Date: Wed, 19 Oct 2016 23:03:27 +1300

Thanks so much that is really helpful. I didn't know there was a new
RFC, and I did look.. I couldn't find it.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Oct 2016 12:20:56 +0200

> RFC, and I did look.. I couldn't find it.

The place to look is the RFC Editor's status page:

<https://www.rfc-editor.org/info/rfc2616>

Best regards, Julian

---

From: Samuel Williams <[email-masked]>
Date: Sun, 30 Oct 2016 22:21:30 +1300

Just as a follow up, I've been using other examples on that page as
part of the unit tests.

However, I am finding it hard to understand the final table:

The media type quality factor associated with a given type is
determined by finding the media range with the highest precedence that
matches the type. 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

would cause the following values to be associated:

Media Type Quality Value
text/html;level=1 q=1
text/html q=0.7
text/plain q=0.3
image/jpeg q=0.5
text/html;level=2 q=0.4
text/html;level=3 q=0.7

But I fail to see, for example, where image/jpeg comes from or, say,
text/html;level=3 because they aren't listed in the given Accept:
header. Is this a documentation bug?

---

From: Samuel Williams <[email-masked]>
Date: Sun, 30 Oct 2016 22:23:55 +1300

Also, just in case anyone is interested, this is for a Ruby gem which
implements RFC compliant parsing of Accept* headers.

https://github.com/ioquatix/http-accept

---

From: Julian Reschke <[email-masked]>
Date: Sun, 30 Oct 2016 11:25:25 +0100

> header. Is this a documentation bug?

"image/jpeg" is covered by "*/*;q=0.5"; "text/html;level=3" is covered 
by "text/html;q=0.7".

Best regards, Julian

---

From: Samuel Williams <[email-masked]>
Date: Mon, 31 Oct 2016 00:15:25 +1300

Thanks Julian, yes I wondered if that was how it was being explained.

> would cause the following values to be associated:

It might be clearer if it were "could be used to compute the following
quality values:"

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 31 Oct 2016 14:29:08 +1300

> It might be clearer if it were "could be used to compute the following

It is not computing quality values. The q values are provided by the
client. It is simply associating those q= values with the possible
response types.

Like so:
1) take the request Accept list
2a) sort by q= value
2b) drop explicit types that cannot be produced (ie xml/tar)
3) output the response for type at the front of the list

If you are writing a client to produce Accept lists, then you should do
the sorting step when generating the request so as to get faster
responses from the server.

Amos

---

From: Samuel Williams <[email-masked]>
Date: Mon, 31 Oct 2016 14:49:21 +1300

Thanks Amos, yes, that's exactly how it works in the code. But thanks
for clarifying it.

The reason why I used the word computed is because it's not a direct
1-1 association. If you want to find the q value for image/jpeg, you
need to first see, is there image/jpeg? no. Is there image/*? no. Is
there */*? Yes. To me, this is a computation, not simply an
association.