- From: Yves Lafon <ylafon@w3.org>
- Date: Tue, 7 Nov 2017 09:56:08 +0100
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
> On 7 Nov 2017, at 09:43, Yves Lafon <ylafon@w3.org> wrote:
>
>
>
>> On 30 Oct 2017, at 12:13, Julian Reschke <julian.reschke@gmx.de> wrote:
>>
>> On 2017-10-30 05:41, Mark Nottingham wrote:
>>> FYI, an update of Variants.
>>> This one removes the requirement for conneg mechanisms to identify their own response header ("Content-*"), in favour of a central one -- Variant-Key.
>>> Doing so avoids the big problem with Variants-00, where the semantics of a header like Content-Encoding could clash with variants' needs.
>>> So, you now have a response that looks something like:
>>> Vary: Accept-Encoding, Accept-Language
>>> Variants: Accept-Encoding;gzip;br, Accept-Language;fr;en;jp
>>> Variant-Key: gzip,en
>>> ... which roughly translates to "There are gzip, brotli and identity representations of this resource, in French, English and Japanese; THIS representation is the gzip'd English one."
>>> ...
>>
>>
>> Looking at the examples, they seem a bit chatty. Can't we collapse this into a single field, like:
>>
>> Variants: Accept-Encoding;available="gzip br";selected=gzip, Accept-Language;available="fr en jp";selected=en
>>
>> ? (and yes, we could abbreviate the parameter names).
>
> It would also help for the rare cases where there is a conflict, like ‘br’ for compression and ‘br’ the language tag, or something like
> Variant-Key: 1 gzip, 2 en in the example above, where the first number is the index in the Variants header value list.
The MUST in the spec is actually taking care of that conflict, so no need for an index there.
--
Baroula que barouleras, au tiéu toujou t'entourneras.
~~Yves
Received on Tuesday, 7 November 2017 08:56:16 UTC