[webkit-dev] X-Purpose on prefetching requests

Adam Barth abarth at webkit.org
Tue Sep 28 12:53:02 PDT 2010

2010/9/28 Alexey Proskuryakov <ap at webkit.org>:
> 28.09.2010, §Ó 9:43, Gavin Peters (ÉwÎı˵Â˹) §ß§Ñ§á§Ú§ã§Ñ§Ý(§Ñ):
>>> I've presented some concerns about the effect of this on enterprise network monitors.
>> I've thought about this some more, and and I think I don't get this
>> actually.  Could you clarify for me?
> I think that it changes false positives to false negatives. Without the header, it will complain about prefetch requests made for Google search results. But once the monitoring software learns to ignore prefetch requests, then it will be easy to circumvent it by adding X-Purpose to every request (e.g. with a browser extension). Doomed both ways.
> It seems that the only real way to make prefetch safe may be to limit it to same origin URLs. Yes, one can always do their own prefetching via a hidden frame, but the purpose of explicit prefetch was to make it semantically clean, and that doesn't seem to work without imposing a same origin restriction.

Hum...  Restricting prefetching to a single origin would seem to
defeat much of the point of the feature in the first place.  Folks who
want to do prefetch will just end up using an image tag instead.

Alexey, it seems like your objection to the X-Purpose header is based
on the belief that servers and network monitors won't use the
information correctly.  Is there evidence that these folks make these
mistakes with the similar X-Moz header used by Firefox?  What about
the X-Purpose header as used by Safari already?

To counterbalance these concerns, we'll gotten feedback from server
operators that they're sad that WebKit lacks the X-Moz header on
prefetch requests, which they find useful.  From talking with these
folks, it seems like they'll live happier lives if we include this
information in prefetch requests.  Given that the cost of including
the information is low and there's already ample implementation
experience from Firefox and Safari, including the information seems
like the right call, on balance.


More information about the webkit-dev mailing list