2010/9/28 Alexey Proskuryakov <a...@webkit.org>: > 28.09.2010, в 9:43, Gavin Peters (�w文彼德斯) написал(а): >>> I've presented some concerns about the effect of this on enterprise network >>> monitors. >> >> I've thought about this some more, and and I think I don't get this >> actually. Could you clarify for me? > > I think that it changes false positives to false negatives. Without the > header, it will complain about prefetch requests made for Google search > results. But once the monitoring software learns to ignore prefetch requests, > then it will be easy to circumvent it by adding X-Purpose to every request > (e.g. with a browser extension). Doomed both ways. > > It seems that the only real way to make prefetch safe may be to limit it to > same origin URLs. Yes, one can always do their own prefetching via a hidden > frame, but the purpose of explicit prefetch was to make it semantically > clean, and that doesn't seem to work without imposing a same origin > restriction.
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. 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? What about the X-Purpose header as used by Safari already? 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. From talking with these folks, it seems like they'll live happier lives if we include this information in prefetch requests. Given that the cost of including the information is low and there's already ample implementation experience from Firefox and Safari, including the information seems like the right call, on balance. Adam
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
