[webkit-dev] X-Purpose on prefetching requests
abarth at webkit.org
Tue Sep 28 16:16:51 PDT 2010
I guess I don't understand your perspective. Are you arguing that
prefetch is a misfeature and folks should use image tags instead?
That doesn't really make sense to me. For example, using an explicit
prefect API means the prefetch gets properly prioritized and doesn't
delay the load event. Below you characterize prefetch as a hack, but
it seems like a useful feature that's used by a bunch of sites.
As for X-Purpose, sometimes you seem to be saying that it can't be
used correctly, whereas other times you seem to be saying that it can
be used correctly, just that sites will screw it up. At the beginning
of the discussion, you seemed worried about the size increase to
requests. Reading your messages, it feels like you don't like
X-Purpose, but you're not quite sure why. As the discussion
progresses, your reasons for disliking it seem to shift.
Server operators seem to be sad that we're don't have the same feature
as Firefox. I don't understand why we shouldn't make them happier.
2010/9/28 Alexey Proskuryakov <ap at webkit.org>:
> 28.09.2010, в 12:53, Adam Barth написал(а):
>> 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.
> Yes, that sounds likely. But why was link prefetch added if it's unnecessary? I have two guesses:
> - syntactic sugar;
> - trying to do it semantically right, providing a way to solve the set of problems with prefetch we've just discussed.
> I think that the discussion that we're having now shows that the second goal cannot be achieved, at least not without some new ideas. Telling servers what part of WebCore initiated the request only shifts the blame on someone else (we've provided complete information to the server, and washed our hands).
>> 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?
> It actually appears that it cannot be used correctly, not just that it won't be.
>>> What about the X-Purpose header as used by Safari already?
> As far as Safari implementation experience goes, I'd like to re-iterate that preview is quite different in this respect, I don't think it's sufficiently related to be given as an example. There is no expectation that fetching a page for preview will make navigating to it faster in the future - and fulfilling that expectation is one of the central problem with prefetch. There is no question of whether fetching for preview means access for network security monitors either - you only prefetch for sites that were previously visited, roughly speaking.
>> 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.
> It's undoubtedly a problem for server operators when another site prefetches their resources indiscriminately (exactly as it would be if someone used display:none or img tag prefetch indiscriminately). Unfortunately, link prefetch looks as if it were less of a hack, encouraging people to use it.
> - WBR, Alexey Proskuryakov
More information about the webkit-dev