Re: [PATCH] variant Key negotiation on error pages

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?

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

Thank you,

Alex.
Received on Thu Mar 21 2013 - 00:34:43 MDT