On Wednesday, February 6, 2013, David Schoonover wrote: > That all sounds fine to me so long as we're all agreed.
Lol. RFC closed. > -- > David Schoonover > [email protected] <javascript:;> > > > On Wed, Feb 6, 2013 at 12:59 PM, Asher Feldman > <[email protected]<javascript:;> > >wrote: > > > On Wednesday, February 6, 2013, David Schoonover 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. > > > > > > Nope. There will be a header denoting non-standard MobileFrontend views > if > > the mobile team wants to leave the caching situation as is. It will be a > > response header set by mediawiki, not varnish. The header will have a > > unique name, it will not share the name of the zero carrier header. The > > udplog field that currently only ever contains carrier information on > zero > > requests will become a key value field. Udplog fields are not named, they > > are positional. > > > > > > > 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? > > > > > > "Bypasses varnish caching" != "bypassing varnish." I don't see any use > of > > the later in this thread, but if there has been confusion, know that all > > m.wikipedia.org requests are served via varnish. > > > > > > > - 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? > > > > > > Nope.. We're repurposing the fixed position udplog field, not the zero > > carrier code header. > > > > > > > > > > > > > *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. > > > > > > > > > Kindly correct me if I've gotten anything wrong. > > > > > > > > > -- > > > David Schoonover > > > [email protected] <javascript:;> > > > > > > > > > On Tue, Feb 5, 2013 at 2:36 PM, Diederik van Liere > > > <[email protected] <javascript:;>>wrote: > > > > > > > > Analytics folks, is this workable from your perspective? > > > > > > > > > > Yes, this works fine for us and it's also no problem to set > multiple > > > > key/value pairs in the http header that we are now using for the X-CS > > > > header. > > > > Diederik > > > > _______________________________________________ > > > > Wikitech-l mailing list > > > > [email protected] <javascript:;> > > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > > > _______________________________________________ > > > Wikitech-l mailing list > > > [email protected] <javascript:;> > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > _______________________________________________ > > Wikitech-l mailing list > > [email protected] <javascript:;> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > _______________________________________________ > Wikitech-l mailing list > [email protected] <javascript:;> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
