W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2020

Are accept-extension parameters used in practice?

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 10 Dec 2020 14:05:35 +0100
To: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <f9426dc6-4bae-4631-7111-16b56f27d0f8@gmx.de>
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
Received on Thursday, 10 December 2020 13:05:52 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 10 December 2020 13:05:54 UTC