Thanks Brandon, that works for me. The cookie has been great btw, we're learning great stuff.
On Wednesday, April 29, 2015, Brandon Black <[email protected]> wrote: > Re: the header name: > > Keep in mind this header does get sent back to clients as a response > header as well. It's probably not a great practice to be using a > generic-sounding header name like "Last" there and waiting to find out > what it conflicts with now or in the future (although I'll note that > the only thing even close in current common use is "Last-Modified"). > The norm would be at least X-Something for a custom weird header, but > I feel the WMF-Something prefix is pretty valid in this context as > well. > > We could blend up the best of all of these concerns if we don't care > about human readability much and just make it something like > "X-WMFLA", too. Regardless, to be honest our pages are so inefficient > and huge on average that I'm not overly concerned about the size of > this one header's name to begin with. There's a ton of lower-hanging > fruit than that to go after for reducing response sizes... > > Re: date formats: > > The stringification VCL offers of the current timestamp "now" was > chosen to match the format used in Expires fields of Cookie headers, > which is rfc822/rfc1123 -based (with 4 digit years and fixed GMT > timezone for best compat with various cookie "standards"), so we get > something like "Wed, 01 Jan 2000 01:01:01 GMT". The form we're using > for Last-Access is just the easiest transformation we could do on that > while throwing out the redundancy and excess precision and making it > compatible with cookie data-value formatting. > > In defense of minimizing our processing complexity here: In general > it's important that we minimize not only the runtime perf hit of our > frontline VCL (as *every* single HTTP request to us runs through this > code, including DDoS attacks and celebrity death traffic inrushes and > such), but also the complexity of the VCL codebase (as it's both > operations-critical and horribly difficult to work on), so we tend to > prefer to offload any post-processing that's not strictly necessary to > elsewhere down the stats pipeline. > > -- Brandon > > _______________________________________________ > Analytics mailing list > [email protected] <javascript:;> > https://lists.wikimedia.org/mailman/listinfo/analytics >
_______________________________________________ Analytics mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/analytics
