On Feb 6, 2013, at 9:32 PM, David Schoonover <dsc(a)wikimedia.org> wrote:
Just want to summarize and make sure I've got the
right conclusions, as
this thread has wandered a bit.
*1. X-MF-Mode: Alpha/Beta Site Usage*
*
*
We'll roll this into the X-CS header, which will now be KV-pairs (using
normal URL encoding), and set by Varnish. This will avoid an explosion of
cryptic headers for analytic purposes.
Questions:
- It seems there's some confusion around "bypassing Varnish". If I
understand correctly, it's not that Varnish is ever bypassed, just that the
upstream response is not cached if cookies are present. Is that right?
Yes
- Since we're repurposing X-CS, should we perhaps
rename it to something
more apt to address concerns about cryptic non-standard headers flying
about?
I'd like to propose to define *one* request header to be used for all analytics
purposes. It can be key/value pairs, and be set client side where applicable. Varnish can
append to it where needed, later keys overriding earlier ones. Then we can log that one
header across all HTTP/caching clusters without having to change the log stream all the
time, and without wasting much space, and caching edge configuration changes are kept to a
minimum as well.
And we might as well be transparent in its naming. header name
"Log-Parameters:"?
*2. X-MF-Req: Primary vs Secondary API Requests*
This header will be replaced with a query parameter set by the client-side
JS code making the request. Analytics will parse it out at processing time
and Do The Right Thing.
I think the question of using a URL param vs a request header should mainly take into
account whether the response varies on the value of the parameter. If the responses are
otherwise identical, and the value is only used for analytics purposes, I would prefer to
put that into the above header instead, as it will impair cacheability / cache size
otherwise (even if those requests are currently not cacheable for other reasons). If the
responses are actually different based on this parameter, I would prefer to have it in the
URL where possible.
--
Mark Bergsma <mark(a)wikimedia.org>
Lead Operations Architect
Wikimedia Foundation