On Thu, Feb 7, 2013 at 4:32 AM, Mark Bergsma <m...@wikimedia.org> wrote:
> > - 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. There's been some confusion in this thread between headers used by mediawiki in determining content generation or for cache variance, and those intended only for logging. The zero carrier header is used by the zero extension to return specific content banners and set different default behaviors (i.e. hide all images) as negotiated with individual mobile carriers. A reader familiar with this might note that their are separate X-CS and X-Carrier headers but X-Carrier is supposed to go away now. Agreed that there should be a single header for content that's strictly for analytics purposes. All changes to the udplog format in the last year or so could likely be reverted except for the delimiter change, with a multipurpose analytics key/value field added for all else. > 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. > For this particular case, the API requests are for either getting specific sections of an article as opposed to either the whole thing, or the first section as part of an initial pageview. I might not have grokked the original RFC email well, but I don't understand why this was being discussed as a logging challenge or necessitating a request header. A mobile api request to just get section 3 of the article on otters should already utilize a query param denoting that section 3 is being fetched, and is already clearly not a "primary" request. Whether or not it makes sense for mobile to move in the direction of splitting up article views into many api requests is something I'd love to see backed up by data. I'm skeptical for multiple reasons. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
