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

On 2017-11-03 01:34, Mark Nottingham wrote:
> ...
>> 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.

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.

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

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

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

> ...

Best regards, Julian

Received on Friday, 3 November 2017 07:05:49 UTC