Re: [PATCH] variant Key negotiation on error pages

On 21/03/2013 1:34 p.m., Alex Rousskov wrote:
> On 03/20/2013 05:40 PM, Amos Jeffries wrote:
>> The Key: header being proposed for standardization replaces and extends
>> the Vary header to provide more fine-grained variant selection by caches.
>>
>> The attached patch add the Key: header on Squid generated error pages so
>> that any receiving clients which support the new header are able to use
>> it for handling our error pages.
>>
>> This also serves as a implementation example for how origin servers can
>> easily implement Key headers alongside Vary headers during the upgrade
>> transition period.
>> see http://tools.ietf.org/html/draft-fielding-http-key-02 for the
>> current specification.
>
>> + // Key:Accept-Language;b="foo"
>> + tmp.append(";b=\"");
>> + tmp.append(err_language);
>> + tmp.append('"');
>
> This will assert when err_language is nil (which happens to be the case
> in the build I just tested).
>
> Note that there is already an err_language checking guard just below the
> minimal diff you posted:
>
>> if (err_language) {
>> rep->header.putStr(HDR_CONTENT_LANGUAGE, err_language);
>> } else
>
> 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.
When a 5-byte is compared with a 2-byte the 2-byte is equivalent to a
wildcard prefix on the 5-byte.
eg "en" MAY be supplied as equivalent to "en-UK" or "en-US" or "en-*"
or "en" or "en-FOO"

Also the way our negotiation happens the first-matching language will be
used and in err_language. Typically this is a sorted list with the more
specific 5-byte forms before the overlapping 2-byte form. So in majority
of cases the 5-byte form will be what we add to the Key header. We may
need to redesign our template aliasing mechanism to de-duplicate those
better, but that is outside scope of this.

For people still using the old Squid error pages with full-name
languages this will insert the longer full name into the Key flag. Which
will not match against any valid ISO code, but will match against that
language used on other responses from this proxy server.

> AFAIK, err_language may contain multiple values (e.g., "en, en-US"). If
> we stuff such a multi-tag language value inside b="..." modifier, will
> it work as intended?

No, err_language contains the single language token - it will be used as
Content-Type header value.
... and Yes whatever err_language contains is the full code or prefix of
a matching language. eg if it ever contains "en, en-US" then the
language code is "en, en-US" not "en" or "en-US".

> I do not think it will match a request with "en"
> language, for example, but it feels like we would want a match in this
> case, right?

Yes. Note that the matching is not being done by Squid here, but by the
remote client.
This is a relevant detail only for the future Squid code which will in
future be doing that matching.

To use the std::find() terminology. The 'b' flag is defined as its value
(needle) being the beginning anchored substring of hay, the needle MAY
be the entire hay.

Thank you for reviewing.
Amos
Received on Thu Mar 21 2013 - 02:09:28 MDT