[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
More information about the webkit-dev