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 with the addition of these
headers, but what is the advantage of having two over one. Wouldn't a
header like:
MobileFrontend: 1/2 a/b/s
work just as fine?

*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | [email protected]


On Sun, Feb 3, 2013 at 4:35 AM, Asher Feldman <[email protected]>wrote:

> 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 that
> can take any value would allow for adding as many extra log values as
> needed, limited only by the uri log field length.
>
> &l=mft2&l=mfstable etc.
>
> So still an edge cache change but the result is more flexible
> while avoiding changing the fixed field length log format across unrelated
> systems like text squids or image caches.
>
> On Sunday, February 3, 2013, Asher Feldman wrote:
>
> > 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. having a fixed field to parse, deal.
> >
> > On Sunday, February 3, 2013, David Schoonover wrote:
> >
> >> Huh! News to me as well. I definitely agree with that decision. Thanks,
> >> Ori!
> >>
> >> I've already written the Varnish code for setting X-MF-Mode so it can be
> >> captured by varnishncsa. Is there agreement to switch to Mobile-Mode, or
> >> at
> >> least, MF-Mode?
> >>
> >> Looking especially to hear from Arthur and Matt.
> >>
> >> --
> >> David Schoonover
> >> [email protected]
> >>
> >>
> >> On Sat, Feb 2, 2013 at 2:16 PM, Diederik van Liere
> >> <[email protected]>wrote:
> >>
> >> > Thanks Ori, I was not aware of this
> >> > D
> >> >
> >> > Sent from my iPhone
> >> >
> >> > On 2013-02-02, at 16:55, Ori Livneh <[email protected]> wrote:
> >> >
> >> > >
> >> > >
> >> > > On Saturday, February 2, 2013 at 1:36 PM, Platonides wrote:
> >> > >
> >> > >> I don't like it's cryptic nature.
> >> > >>
> >> > >> Someone looking at the headers sent to his browser would be very
> >> > >> confused about what's the point of «X-MF-Mode: b».
> >> > >>
> >> > >> Instead something like this would be much more descriptive:
> >> > >> X-Mobile-Mode: stable
> >> > >> X-Mobile-Request: secondary
> >> > >>
> >> > >> But that also means sending more bytes through the wire :S
> >> > > Well, you can (and should) drop the 'X-' :-)
> >> > >
> >> > > See http://tools.ietf.org/html/rfc6648: Deprecating the "X-" Prefix
> >> and
> >> > Similar Constructs in Application Protocols
> >> > >
> >> > >
> >> > > --
> >> > > Ori Livneh
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > _______________________________________________
> >> > > Wikitech-l mailing list
> >> > > [email protected]
> >> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >> >
> >> > _______________________________________________
> >> > Wikitech-l mailing list
> >> > [email protected]
> >> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >> >
> >> _______________________________________________
> >> Wikitech-l mailing list
> >> [email protected]
> >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> >
> _______________________________________________
> Wikitech-l mailing list
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to