[Webkit-unassigned] [Bug 46529] Output X-Purpose header for prefetch requests

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=46529





--- Comment #11 from Gavin Peters <gavinp at chromium.org>  2010-09-24 16:41:01 PST ---
(In reply to comment #9)
> (From update of attachment 68781 [details])
> Wait, how is it a good idea to make requests larger?

Alexey, thanks for helping review!

This patch does nothing to most requests.  To some requests, derived from <link rel="prefetch" href="..."> this patch will add a header marking this request as a prefetch "X-Purpose: prefetch".  Everything else is left completely untouched; take a look at the unit test and you'll see it has to be fairly careful about how it arranges things to even generate the header (and trickier still to check it).

Right now, there's three implementations of prefetching and prefetching like behaviour.  Mozilla, when following Link prefetches, adds an "X-Moz: prefetch" header, which is admittedly four bytes shorter.  Safari, when generating its bitmap previews, attaches a header "X-Purpose: preview" (which is one byte shorter).

Lots of website operators care about prefetch requests, and want to distinguish them.  For instance, IMDB and Wikipedia block incoming requests based on the X-Moz header; they 404 these requests, and then a later user initiated navigation will load the page.  We didn't implement X-Moz, since the name is so ugly, but I wanted something that gave web site operators a chance to see this.  As well, I have started discussions in the HTTPbis working group to standardize this header name, so it may change to just "Purpose" sometime soon.

Google searching on X-Purpose finds lots of folks who mutate their site a bit for the (heavier weight) Safari preview loads.  Analytics are typically removed.

Another use case of this header is log analysis; website operators may want to distinguish link prefetches from user initiated navigation.

If you're trying to make the case that link prefetches shouldn't be signalled to server operators at all, I think you'll find that's not going to be a very popular idea with server operators.  I think if browsers are going to do prefetching (right now, I'm aware that Chrome & the Android browser do, I do not believe any others have it enabled), then they should signal to the server that they use it.

Does the above address your concerns?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.