Subject: Are accept-extension parameters used in practice?

From: Julian Reschke <[email-masked]>
Date: Thu, 10 Dec 2020 14:05:35 +0100

Hi there,

(this is <https://github.com/httpwg/http-core/issues/568>).

So while reviewing the core specs, I stumbled upon "accept extension
parameters", which have been in the specs for ... long.

Citing <https://tools.ietf.org/html/rfc2068#section-14.1>:

>           Accept         = "Accept" ":"
>                            #( media-range [ accept-params ] )
>
>           media-range    = ( "*/*"
>                            | ( type "/" "*" )
>                            | ( type "/" subtype )
>                            ) *( ";" parameter )
>
>           accept-params  = ";" "q" "=" qvalue *( accept-extension )
>
>           accept-extension = ";" token [ "=" ( token | quoted-string ) ]
>
>    The asterisk "*" character is used to group media types into ranges,
>    with "*/*" indicating all media types and "type/*" indicating all
>    subtypes of that type. The media-range MAY include media type
>    parameters that are applicable to that range.
>
>    Each media-range MAY be followed by one or more accept-params,
>    beginning with the "q" parameter for indicating a relative quality
>    factor. The first "q" parameter (if any) separates the media-range
>    parameter(s) from the accept-params. Quality factors allow the user
>    or user agent to indicate the relative degree of preference for that
>    media-range, using the qvalue scale from 0 to 1 (section 3.9). The
>    default value is q=1.

So, if you have

    Accept: text/html;level=1;q=0.5

"level" is a parameter of the media type "text/html".

On the other hand, in

    Accept: text/html;q=0.5;level=1

"level" is an accept-extension.

Has anyone ever *seen* this in use?

For the spec, we could:

0) leave things as they are

1) note that this is not in use, advise not to send it, and advise
recipients to ignore it (essentially deprecating it)

2) kill it completely

3) ...?

Feedback appreciated,

Julian

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 10 Dec 2020 16:35:23 +0100

Hi Julian,

> Has anyone ever *seen* this in use?

Wow, I'm pretty sure I never noticed this. Even the q= I've probably
seen it more often in specs than in traces, so the two combined should
be extremely rare..

> recipients to ignore it (essentially deprecating it)

Not having ever met it I could be in favor of 2 but if it used to be
valid it's a bit harsh for past implementers who tried hard to comply
with the specs so probably 1 would be more suitable (like we did for
the chunk extensions).

Just my two cents,
Willy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 10 Dec 2020 09:59:09 -0800

> On Dec 10, 2020, at 7:35 AM, Willy Tarreau <[email-masked]> wrote:
> 
> Hi Julian,
> 

FWIW, I have never seen it used in practice. IIRC, I added accept-ex
due to a hypothetical question about how to distinguish between the media
type parameters and other global parameters we might add in the future to
be like q. We never added such parameters, and I doubt that we could do
so now without breaking someone.

So, I'm +1 to remove them. But if anyone has seen them in use, please
let us know.

Cheers,

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 11 Dec 2020 11:45:17 +1100

My .02 -

Remove them, but make sure to highlight that 'q' should be the last parameter, so that a recipient who actually read this text doesn't classify media-range parameters as accept-extensions. Like Roy, I've never seen this in use; if it happens, I strongly suspect that the sender intended to send media-range parameters, not accept-extensions (which don't have an obvious purpose, unless someone wants to invent a replacement for `q`).

Cheers,

> On 11 Dec 2020, at 12:05 am, Julian Reschke <[email-masked]> wrote:
> 
> Hi there,
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Dec 2020 16:15:58 +0100

Am 11.12.2020 um 01:45 schrieb Mark Nottingham:
> ...

Change proposal in <https://github.com/httpwg/http-core/pull/615>.
Feedback appreciated.

Best regards, Julian