On Sun, Feb 3, 2013 at 2:35 AM, Asher Feldman afeldman@wikimedia.orgwrote:
Regarding varnish cacheability of mobile API requests with a logging query param - it would probably be worth making frontend varnishes strip out all occurrences of that query param and its value from their backend requests so they're all the same to the caching instances. A generic param name that can take any value would allow for adding as many extra log values as needed, limited only by the uri log field length.
&l=mft2&l=mfstable etc.
So still an edge cache change but the result is more flexible while avoiding changing the fixed field length log format across unrelated systems like text squids or image caches.
On Sunday, February 3, 2013, Asher Feldman wrote:
If you want to differentiate categories of API requests in logs, add descriptive noop query params to the requests. I.e &mfmode=2. Doing this
in
request headers and altering edge config is unnecessary and a bad design pattern. On the analytics side, if parsing query params seems challenging vs. having a fixed field to parse, deal.
Asher, I understand your hesitation about using HTTP header fields, but there are a couple problems I'm seeing with using query string parameters. Perhaps you or others have some ideas how to get around these: * We should keep user-facing URLs canonical as much as possible (primarily for link sharing) ** If we keep user-facing URLs canonical, we could potentially add query string params via javascript, but that would only work on devices that support javascript/have javascript enabled (this might not be a huge deal as we are planning changes such that users that do not support jQuery will get a simplified version of the stable site) * How could this work for the first pageview request (eg a user clicking a link from Google or even just browsing to http://en.wikipedia.org)?
I may be missing other potential problems - it would be great if others from the mobile team could chime in.