When the prefetch feature was originally added to WebKit, the first patch (bug 3652), it had a header X-Moz, for backwards compatibility with Firefox. Currently, when Firefox follows link prefetch requests, it adds a header "X-Moz: prefetch" to the request. However, before 3652 was landed, we removed this. The "X-Moz" header is pretty ugly, it has a very bad name.
I felt a bit unsatisfied about this, so today I circled back and landed a patch to cause WebKit, when following prefetches, to send an "X-Purpose: prefetch" header, which is modelled closely on the "X-Purpose: preview" header that is sent by Safari when it does its preview generating loads (for those pictures of websites you see on the new tab screen). That patch is in bug 46529. I've also started a discussion in the HTTPbis working group about the three incompatible methods of notification that exist (X-Moz, X-Purpose, and do nothing), to see if a new header "Purpose" makes sense. The X-Purpose patch was controversial though; so Alexey Proskuryakov suggested we start a discussion in the mailing list. Right now, as I see it (and please chime in with what I'm missing), points in favour of sending X-Purpose are: - Conformity. Existing browsers that do prefetching/previewing notify servers, WebKit browsers should follow this. - Differentiation. Allows some kinds of differential treatment. A heavily loaded server may not want to serve prefetches, and 500 them. Some servers today 404 all X-Moz requests; while I think that's a shame, it is good to let people opt out of a feature. - Statistics. Server authors may wish to distinguish the origins of their traffic; although of course this is tricky, since prefetch loads are not always viewed and not always ignored. (send Cache-Control: must-revalidate) to prefetch requests, and you'll accurately know about uses, although at some cost in latency for your users. - Monitoring. Perhaps your web monitoring software or network operations department would like to know the difference between user navigation, and browser-initiated navigation. However, against X-Purpose, we have: - Acceptance. We want prefetching to succeed, and this header will promote opt-out. Besides, opt-out after getting the request is slow anyway. - Cost. Why make requests longer than they need to be? - Dangerous. If people vary content based on this header, they could cause all sorts of caching troubles (for instance a proxy might cache a 404 from a server that's differentiating traffic). What do people think? From I think we should follow existing practice, and send the header. I don't think the header cost is very big, and I am not sure that caching 404s is defensible anyway. Lots of headers shouldn't be used to mutate content; this is not new. Thoughts? - Gavin For the original landing of prefetching, see: https://bugs.webkit.org/show_bug.cgi?id=3652 For this new bug, see: https://bugs.webkit.org/show_bug.cgi?id=46529 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev