<meta charset="utf-8"><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><div>Two weeks ago, I tried to land a patch in bug 46529 to add an &quot;X-Purpose: prefetch&quot; request header to link prefetch motivated requests from WebKit.  I&#39;d like to land this change, as I think it&#39;s an important part of making link prefetch work well.  Link prefetching is part of HTML5.  Link prefetching has been implemented by the Firefox browser for years.   Chrome&#39;s prefetching experiments have shown that prefetching on the web today makes browsing faster.</div>

<div><br></div><div>Currently, Firefox&#39;s longstanding prefetch implementation sends a request header &quot;X-Moz: prefetch&quot; on its prefetch requests.  The proposed header name &quot;X-Purpose&quot; was chosen because it is what Safari already uses for its bitmap previews.  In particular, Safari sends &quot;X-Purpose: preview&quot; headers on requests for resources and subresources motivated by the previw feature of Safari.  I&#39;ve also started a discussion in HTTPbis about changing this header to simply &quot;Purpose&quot;.  That has not been decided yet, and I think we can go forward with &quot;X-Purpose&quot;, and rename the header as soon as there&#39;s good consensus in HTTPbis.</div>

<div><br></div><div>Servers will use the &quot;X-Purpose&quot; header for a number of purposes.  Servers under load may 500 prefetch requests, rather than server non-navigation motivated requests.  Servers may 500 prefetch requests that would have retrieved non-cacheable content.  Server operators who want accurate information on user-initiated navigations to their resources can use this header: when prefetch motivated requests arrive, they can respond with &quot;Cache-Control: must-revalidate&quot; which should force a 304 at user-initiated navigation[1].  Some server operators today opt-out of X-Moz prefetch motivated requests, and that may continue to happen.</div>

<div><br></div><div>The X-Purpose header will not make requests any longer or different, except for prefetching motivated requests (which will be longer by about 20 bytes).  Nor will this header make server response headers longer.  Alexey in our earlier discussion was concerned that all server responses would have to have to be longer due to &quot;Vary: X-Purpose&quot; responses.  This turns out to not be the case; a Vary response to prefetches doesn&#39;t make sense, since the entire purpose of the feature is to prime caches.  To treat prefetch requests differently, instead 500 them as described above, or use the &quot;Cache-Control: must-revalidate&quot; trick above.</div>

<div><br></div><div>Alexey asked how X-Purpose headers will affect corporate network monitoring software; he was particularly concerned that this header would make reports from network monitoring software less accurate.  This turns out to not be the case; prefetches right now transit the network unmarked.  The proposal is to mark prefetch motivated requests, which is more information than we had previously.  Today you can&#39;t attribute any resource request to user navigation (since it might be prefetch motivated), but with this header, you have some requests (prefetch motivated requests that didn&#39;t use the cache-control trick) that you can&#39;t attribute user navigation to.  So network monitoring has strictly more information.</div>

<div><br></div><div>Eric Seidel, in the X-Purpose bug, asked why we&#39;d tag prefetch motivated requests, when we don&#39;t, for instance, tag iframe or XMLHttpRequest motivated requests.  I think the difference here is that there&#39;s effective conditional handling that servers can make; there are a wide variety of responses that servers can make to prefetches, discussed above, all of which result in well defined resources &amp; load semantics for user navigation.  In the case of iframes, even display:none iframes or XMLHttpRequest, the result of this kind of differential handling is undefined: without putting very difficult to enforce requirements on pages themselves, it will stay undefined.</div>

<div><br></div><div>Maciej last week suggested he&#39;d get back to us and explain the motivations that the Safari team used for adding &quot;X-Purpose: preview&quot;, in case they were helpful here.  He hasn&#39;t yet, but I&#39;m sure I&#39;d appreciate hearing about that!</div>

<div><br></div><div>Have I missed anything?  I think X-Purpose (or Purpose, or X-Moz...), is an important part of a link prefetching implementation.  It&#39;s requested by server operators, it has been used in the X-Moz form for years, and it helps servers gather statistics properly &amp; handle load.  It also makes network monitoring software more accurate.  And all this, without significantly lengthening requests.  I hope I don&#39;t sound thick headed here, but I don&#39;t see a downside.</div>

<div><br></div><div>Can we go ahead and land this change?  Is there something missing from the above?  If something is missing, please reply and explain what it is and how you think it might be addressed.  Thanks!</div><div>

<div><br></div></div><div>- Gavin</div><div><br></div><div>[1] Unfortunately, such servers are losing some of the benefit of prefetching since there&#39;s at least one critical-path RTT, and possibly two (if no warm TCP connection is available) for these kinds of validated navigations.</div>

</span>