Just to tie this thread up - the issue of how to count ajax driven
pageviews loaded from the api and of how to differentiate those requests
from secondary api page requests has been resolved without the need for
code or logging changes.
Tagging of the mobile beta site will be accomplished via a
Thanks Asher for tying this up! I was about to write a similar email :)
One final question, just to make sure we are all on the same page: is the
X-CS field becoming a generic key/value pair for tracking purposes?
D
On Fri, Feb 15, 2013 at 11:16 AM, Asher Feldman afeld...@wikimedia.orgwrote:
It does still seem to me that the data to determine secondary api requests
should already be present in the existing log line. If the value of the
page param in an action=mobileview api request matches the page in the
referrer (perhaps with normalization), it's a secondary request as per case
On Tuesday, February 12, 2013, Diederik van Liere wrote:
It does still seem to me that the data to determine secondary api
requests
should already be present in the existing log line. If the value of the
page param in an action=mobileview api request matches the page in the
referrer
On 11.02.2013, 22:11 Asher wrote:
And then I'd wonder about the server side implementation. How will frontend
cache invalidation work? Are we going to need to purge every individual
article section relative to /w/api.php on edit?
Since the API doesn't require pretty URLs, we could simply
Max - good answers re: caching concerns. That leaves studying if the bytes
transferred on average mobile article view increases or decreases with lazy
section loading. If it increases, I'd say this isn't a positive direction
to go in and stop there. If it decreases, then we should look at the
I'm a bit worried that now we are asking why pages are lazy loaded
rather than focusing on the fact that they currently __are doing
this___ and how we can log these (if we want to discuss this further
let's start another thread as I'm getting extremely confused doing so
on this one).
Lazy loading
Thanks, Jon. To try and clarify a bit more about the API requests... they
are not made on a per-section basis. As I mentioned earlier, there are two
cases in which article content gets loaded by the API:
1) Going directly to a page (eg clicking a link from a Google search) will
result in the
Thanks for the clarification Arthur, that clears up some misconceptions I
had. I saw a demo around the allstaff where individual sections were lazy
loaded, so I think I had that in my head.
It does still seem to me that the data to determine secondary api requests
should already be present in
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
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
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
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
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
That all sounds fine to me so long as we're all agreed.
--
David Schoonover
d...@wikimedia.org
On Wed, Feb 6, 2013 at 12:59 PM, Asher Feldman afeld...@wikimedia.orgwrote:
On Wednesday, February 6, 2013, David Schoonover wrote:
Just want to summarize and make sure I've got the right
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
d...@wikimedia.org javascript:;
On Wed, Feb 6, 2013 at 12:59 PM, Asher Feldman
afeld...@wikimedia.orgjavascript:;
wrote:
On
On Mon, Feb 4, 2013 at 7:12 PM, Asher Feldman afeld...@wikimedia.orgwrote:
On Mon, Feb 4, 2013 at 5:21 PM, Asher Feldman afeld...@wikimedia.org
wrote:
On Mon, Feb 4, 2013 at 4:59 PM, Arthur Richards aricha...@wikimedia.org
wrote:
In the case of the cookie, the header would actually get
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
On Sun, Feb 3, 2013 at 2:35 AM, Asher Feldman afeld...@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
On Mon, Feb 4, 2013 at 4:24 PM, Arthur Richards aricha...@wikimedia.orgwrote:
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
On Mon, Feb 4, 2013 at 5:30 PM, Brion Vibber br...@pobox.com wrote:
On Mon, Feb 4, 2013 at 4:24 PM, Arthur Richards aricha...@wikimedia.org
wrote:
Asher, I understand your hesitation about using HTTP header fields, but
there are a couple problems I'm seeing with using query string
On Mon, Feb 4, 2013 at 4:38 PM, Arthur Richards aricha...@wikimedia.orgwrote:
On Mon, Feb 4, 2013 at 5:30 PM, Brion Vibber br...@pobox.com wrote:
On Mon, Feb 4, 2013 at 4:24 PM, Arthur Richards aricha...@wikimedia.org
wrote:
* How could this work for the first pageview request (eg a user
On Mon, Feb 4, 2013 at 5:49 PM, Brion Vibber br...@pobox.com wrote:
On Mon, Feb 4, 2013 at 4:38 PM, Arthur Richards aricha...@wikimedia.org
wrote:
On Mon, Feb 4, 2013 at 5:30 PM, Brion Vibber br...@pobox.com wrote:
On Mon, Feb 4, 2013 at 4:24 PM, Arthur Richards
On Mon, Feb 4, 2013 at 4:24 PM, Arthur Richards aricha...@wikimedia.orgwrote:
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
On Mon, Feb 4, 2013 at 4:59 PM, Arthur Richards aricha...@wikimedia.orgwrote:
In the case of the cookie, the header would actually get set by the backend
response (from Apache) and I believe Dave cooked up or was planning on
cooking some magic to somehow make that information discernable when
On Mon, Feb 4, 2013 at 5:21 PM, Asher Feldman afeld...@wikimedia.orgwrote:
On Mon, Feb 4, 2013 at 4:59 PM, Arthur Richards
aricha...@wikimedia.orgwrote:
In the case of the cookie, the header would actually get set by the
backend
response (from Apache) and I believe Dave cooked up or was
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.
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
Considering that the query component of a URI is meant to identify the
resource whereas HTTP headers are meant to tell the server additional
information about the request, I think a header approach is much more
appropriate than a no-op query parameter.
If the X- is removed, I'd have no problem
That's not at all true in the real world. Look at the actual requests for
google analytics on a high percentage of sites, etc.
Setting new request headers for mobile that map to new inflexible fields in
the log stream that must be set on all non mobile requests (\t-\t-)
equals gigabytes of
Remind me again why a production setup is logging every header of every
request? Also, if you are logging every header, then the amount of data
added by a single extra header would be insignificant compared to the rest
of the request.
*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of
On Sunday, February 3, 2013, Tyler Romeo wrote:
Remind me again why a production setup is logging every header of every
request?
That's ludicrous. Please reread our udplog format documentation and this
entire thread carefully, especially the first message before commenting any
further.
32 matches
Mail list logo
