[Product-Developers] HTTP caching, browser view output cached per-locale (Vary: Accept-Language)

[Sean Upton]

I need to have varnish cache per-locale (or close to it) the output of
a browser-view in an add-on I maintain (JavaScript variant based on
locale).

How reasonable is it to serve a browser view that differs and is
cacheable (varnish) per-locale (in my add-on, a view that outputs
locale-specific JavaScript, and which is included in JS registry)?  I
want to use Vary: Accept-Language in the response headers.

Obviously, the cache hits in Varnish depend on both the Vary:
Accept-Language response header, and some kind of reasonably condensed
Accept-Language request header, I assume (untested) something like
this to strip the qvalue:

sub vcl_recv {
    set req.http.Accept-Language = regsub(req.http.Accept-Language,
"^(.*);(.*)$", "\1");
    /* ... */
}

For my locale for example, "en-US,en;q=0.5" (Firefox), and
"en-US,en;q=0.8" (Chrome) could be condensed to the same value
"en-US,en" for purposes of increasing cache hits?

At the moment, I use a view called every request that issues a 302
redirect to a locale-specific static javascript resource.  I suspect
this redirect-view-plus-static-resource is less optimal than just
serving the script from a view (use plone.memoize.ram caching keyed on
locale, then also caching upstream in Varnish). Browsers and varnish
can both be capable of caching it once, even though the script is used
on every page in the Plone site.  Caching once per session seems more
reasonable than serving the uncachable 302 redirect on every page?

Does using Vary and rewriting Accept-Language seem reasonable?  Is
there a better way?

Sean