Re: [PATCH] variant Key negotiation on error pages

On 03/21/2013 02:38 AM, Amos Jeffries wrote:
> On 21/03/2013 5:45 p.m., Alex Rousskov wrote:
>> If I am interpreting draft-fielding-http-key-02 correctly, there is no
>> point in sending
>>
>> Vary: Accept-Language
>> Key: Accept-Language
>>
>> because both of the above header fields have identical semantics
>> (Section 2). Did I misunderstood?

> "
> When a cache
> fully implements this mechanism, it MAY ignore the Vary response
> header field.
> "
>
> Which does not limit the ignoring of Vary to just Vary+Key responses.

I think it does. If implementing Key specs is enough to ignore all Vary
headers in all responses, somebody better tell that to all the servers
that send Vary and do not know about Key! The Key draft does not
obsolete RFC 2616. It cannot make irrelevant the Vary header sent by
servers that do not send the Key header.

One should ask what is a "server" in this context. My conservative
answer would be that it is the "sender" in HTTPbis sense: If a message
lacks Key, the recipient MUST NOT ignore Vary.

> So
> until (and if) the spec gets updated to mandate following Vary whenever
> Key is absent

RFC 2616 mandates that IMO. However, since we are arguing about it,
somebody should let Mark know that they need to add some explicit draft
language about that.

> its best to always emit Key+Vary for the same reasons that
> it is best to always emit Vary if *any* of the URLs responses needs it.

I agree, but only when Key differs from Vary for at least one response.
If all responses are going to have the same Key and Vary, there is no
need to send Key. Doing so would only waste resources.

> Otherwise we risk causing for Key the same problem that Apache caused
> for Vary - one response coming back with *no* key gravitating all future
> traffic to that variant regardless of others existence.

I do not think this is the same situation because Vary:v implies Key:v.
Sending just Vary is enough if you do not need the extra functionality
offered by Key. Any code that supports Key but receives Vary without Key
ought to process the Vary value as if it is a Key value. There will be
no gaps in coverage.

If my interpretation is wrong, the draft should be clarified.

>>>> If the negotiated language was "xfo" and the later requested language
>>>> happens to be "xfoobar", will the "xfo" language response be served to
>>>> an "xfoobar" reader because of the "prefix match" logic of the b=".."
>>>> modifier? Is that a good thing?

>>> Yes and yes. Due to the way the codes are syntaxed the valid ones are
>>> all 2 or 5 bytes long with an optional trailer.

>> Well, many languages have three letters in the primary tag (e.g., duh
>> for Dungra Bhil) and other length are allowed, but what is important
>> here is whether a language tag may be a prefix of another, completely
>> unrelated language tag. If yes, then using the prefix b="..." modifier
>> would be wrong IMHO.
>>
>> For example, should a cached English ("en") error page be served to an
>> Emumu-speaking client?

> Hmm. Yes I see they extended the tags beyond ISO-639-1 set now.

And there are (and always have been) various private/extension tags that
do not require IANA registration. We have to work with what is valid,
not with what is registered, especially if we want to claim that this
code "serves as a implementation example for how origin servers can
easily implement Key headers". Based on this discussion, a correct,
useful implementation may not just be difficult, it may be impossible.

> If we send ;b= the 2-bytes will match against 3-bytes codes.

Agreed.

> But if we
> send ;p= then 2-byte will fail to match against the more common 5-byte
> wildcards. For example env vs en-*.

Agreed, except the example is "en vs en-*".

>> Type: language
>> Subtag: enr
>> Description: Emumu
>> Description: Emem
>> Added: 2009-07-29

>> Type: language
>> Subtag: en
>> Description: English
>> Added: 2005-10-16

>> I could not find any rules that prohibit one language tag to be a prefix
>> of another. It is possible that I missed them (not my area of
>> expertise), but the above counter-example with Emumu/English seems to
>> indicate that there is no such prohibition?

> In practice from my archive of Accept-Languge headers collected from
> around the net over the last few years there are no 3-byte codes in use
> (so far).
>
> So the question is do we want to cater to the rare case by compromising
> a more common form of breakage? I think no.

Sending Vary: Accept-Language does not really compromise or break
anything, does it? It might not be as efficient as 'Key:
Accept-Language;b="en"' but since the latter Key is incorrect, perhaps
we should avoid this minor optimization instead of introducing a bug?

The question, I think, should be whether Key modifiers should be
extended to address the common case of Accept-Language correctly. If and
when that happens, we would be able to optimize without introducing bugs.

Thank you,

Alex.
Received on Thu Mar 21 2013 - 17:02:30 MDT