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. Adam 2010/9/28 Alexey Proskuryakov <a...@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 > > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
