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

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. Also, even with shorter parameter names, it seems like this approach is actually more verbose, in terms of character counts -- especially when the list gets long.

Hmmm.

You get the additional complexity of two header fields potentially out 
of sync. My gut feeling is that eliminating that problem would be worth 
a few bytes.

And if optimizing *that* is the goal, one can of course choose a bit 
more obscure syntax, such as:

   Accept-Encoding;gzip,gzip,br, Accept-Language;en;fr;en;jp

(where the first parameter indicates the selected variant)

>> Also, looking at my made up syntax using whitespace as separator reminds me that picking the separator is tricky, and in particular the semicolon might not work well in all cases. For instance, what if the server was negotiating on "Accept" and take parameters into account? (see example in <https://www.greenbytes.de/tech/webdav/rfc7231.html#rfc.section.5.3.2.p.10>).
>>
>> So, whatever the syntax is we probably need an escaping mechanism for edge cases...
> 
> Yes (and that's another reason for separating the headers, I think).

Why? The escaping problem exists in both cases...

> However, keep in mind that available-values doesn't *have* to be the values sent in the request headers; it can be computed to something else.
> 
> Also, I very much wonder whether including parameters is a good idea for Accept.

Yes, but that's a separate discussion. I believe it would be good if the 
draft addressed negotiating on type (no matter whether we think it's a 
good idea).

> ...

Best regards, Julian

Received on Tuesday, 31 October 2017 07:56:26 UTC