[webkit-dev] X-Purpose on prefetching requests

Gavin Peters (蓋文彼德斯) gavinp at chromium.org
Fri Sep 24 22:26:37 PDT 2010

On 24 September 2010 21:27, Alexey Proskuryakov <ap at webkit.org> wrote:
> 24.09.2010, в 17:31, Gavin Peters (蓋文彼德斯) написал(а):
>> - Cost.  Why make requests longer than they need to be?
> If used correctly, this will make responses longer, too (due to Vary: X-Purpose). Due to the nature of Vary, it will need to be sent with every response for the resource, not just those that are in response to prefetch requests.

I think I might be missing this point.  For the purposes of
prefetching, I think that once you send out a "Vary: X-Purpose"
header, you've basically opted out of permitting prefetching.  Why
wouldn't such a site send out a non-cacheable failure to prefetching
requests?  A 500 or 404 would likely not cause a cache discard, and so
an eventual user navigation will just cause cache validation; but
that's OK: the prefetch wouldn't have resulted in network activity if
the cache was fresh anyway.

Is there another case I'm forgetting or not understanding?  I can see
how this might be different in the "X-Purpose: preview" case, but that
cat's out of the bag.

> Eric has made another good point in Bugzilla - we don't explain the purpose in lots of other cases, from loading into a display:none frame to XMLHttpRequest. Why should Prefetch be all the different?

That I don't have a good answer to; we don't.  For prefetching
browsers traditionally have, but for these cases they haven't.
Prefetching is not all that different than a display:none frame I

- Gavin

More information about the webkit-dev mailing list