On Thu, Feb 7, 2013 at 4:32 AM, Mark Bergsma <mark(a)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.