Re: New Version Notification for draft-nottingham-variants-01.txt

> On 31 Oct 2017, at 10:13 pm, Julian Reschke <julian.reschke@gmx.de> wrote:
> 
> On 2017-10-31 00:08, Mark Nottingham wrote:
>> On 30 Oct 2017, at 10:13 pm, 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).
>> I considered that, but it seems like making them separate will make at least the Variants header (in the current design) more likely to get a hit in HPACK. (...)
> 
> Just checking: that's mainly true when multiple UAs share the same connection, right? For a single UA, I would assume that during normal operation, most of the time the same variant would be selected, so inlining the "selected" information wouldn't hurt...

Yes. Multiple UAs is an important use case, however.


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

Received on Friday, 3 November 2017 00:35:54 UTC