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

From: Mark Nottingham <[email-masked]>
Date: Fri, 3 Nov 2017 11:35:29 +1100

> On 31 Oct 2017, at 10:13 pm, Julian Reschke <[email-masked]> wrote:
> 
> On 2017-10-31 00:08, Mark Nottingham wrote:
>> On 30 Oct 2017, at 10:13 pm, Julian Reschke <[email-masked]> 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/

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 3 Nov 2017 11:34:29 +1100

> On 31 Oct 2017, at 6:55 pm, Julian Reschke <[email-masked]> wrote:
> 
>> 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.

I don't see it as a huge problem; if they're out of sync, it implies that the server is very confused about its state. A MUST about values in Variant-Key that aren't in Variants, and one that the MUST be the same length should take care of it. 

> 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)

I think that's going to be much more difficult for people to understand; consider how much confusion there is out there about Vary.

>>> 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...

Multiple layers of escaping.

>> 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).

I agree, but I don't want to put work into it until the draft has a future.

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Fri, 3 Nov 2017 08:01:20 +0100

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

Could you elaborate about the use case for clarity? That's in the 
backend, right?

---

From: Julian Reschke <[email-masked]>
Date: Fri, 3 Nov 2017 08:05:20 +0100

> I don't see it as a huge problem; if they're out of sync, it implies that the server is very confused about its state. A MUST about values in Variant-Key that aren't in Variants, and one that the M…

My concerns are:

1) It might be impossible to detect when they are out of sync.

2) We know about all the issues people have with setting header fields 
(-> stackoverflow), so adding another thing that they can get wrong 
might be a bad idea.

> I think that's going to be much more difficult for people to understand; consider how much confusion there is out there about Vary.

I'll claim that the current proposal where the field names aren't 
repeated in the other field is as hard to understand :-).

> Multiple layers of escaping.

? You'll need one layer of escaping in both cases.

Best regards, Julian

---

From: azam azman <[email-masked]>
Date: Mon, 6 Nov 2017 10:39:47 +0800

Pada 6 Nov 2017 10:28 PG, "Julian Reschke" <[email-masked]> menulis:

>>> 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.
>>>
>>
>> I don't see it as a huge problem; if they're out of sync, it implies that
>> the server is very confused about its state. A MUST about values in
>> Variant-Key that aren't in Variants, and one that the MUST be the same
>> length should take care of it.
>>
>
> My concerns are:
>
> 2) We know about all the issues people have with setting header fields (->
> stackoverflow), so adding another thing that they can get wrong might be a
> bad idea.
>
>> I think that's going to be much more difficult for people to understand;
>> consider how much confusion there is out there about Vary.
>>
>
> I'll claim that the current proposal where the field names aren't repeated
> in the other field is as hard to understand :-).
>
> 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.sect
>>>>> ion.5.3.2.p.10>).
>>>>>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Nov 2017 11:22:58 +1100

> On 3 Nov 2017, at 6:01 pm, Julian Reschke <[email-masked]> wrote:
> 
> Could you elaborate about the use case for clarity? That's in the backend, right?

"back end", CDN, non-browser, etc.

---

From: azam azman <[email-masked]>
Date: Tue, 7 Nov 2017 09:18:11 +0800

fail baru
<https://docs.google.com/document/d/1qWa9L_ojCH-pQ-8dOUPR28M25uzgazmAnKEL4j2X6xM/edit?usp=drivesdk>

Pada 6 Nov 2017 10:09 PG, "Mark Nottingham" <[email-masked]> menulis:

> >>>> 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.
> >>>> ... 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."
> >>>> ...
> >>>
> >>>
> >>> Variants: Accept-Encoding;available="gzip br";selected=gzip,
> Accept-Language;available="fr en jp";selected=en
> >>>
> >> 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...
>

---

From: Yves Lafon <[email-masked]>
Date: Tue, 7 Nov 2017 09:43:45 +0100

> On 30 Oct 2017, at 12:13, Julian Reschke <[email-masked]> wrote:
> 

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.

> Finally, a question about <https://mnot.github.io/I-D/variants/#rfc.section.3>:
> 
>> Note that the contents of Variant-Key are only used to indicate what request attributes are identified with the response containing it; this is different from headers like Content-Encoding, which indicate attributes of the response. In the example above, it might be that a gzip’d version of the French content is not available, in which case it will not include “Content-Encoding: gzip”, but still have “gzip” in Variant-Key.
> 
> Am I right that this just follows from the syntax that requires Variants and Variant-Keys have the same number of list elements? That might be another reason to collapse things into a single field.
> 
> Best regards, Julian
> 
> 
> 

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

        ~~Yves

---

From: Yves Lafon <[email-masked]>
Date: Tue, 7 Nov 2017 09:56:08 +0100

> On 7 Nov 2017, at 09:43, Yves Lafon <[email-masked]> wrote:
> 
> 
> 

The MUST in the spec is actually taking care of that conflict, so no need for an index there.

        ~~Yves