On Feb 6, 2013, at 9:32 PM, David Schoonover <d...@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 <m...@wikimedia.org> Lead Operations Architect Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
