[webkit-dev] X-Purpose, again!

[Gavin Peters (蓋文彼德斯)]

Two weeks ago, I tried to land a patch in bug 46529 to add an "X-Purpose:
prefetch" request header to link prefetch motivated requests from WebKit.
 I'd like to land this change, as I think it'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's prefetching experiments have shown that prefetching on the web
today makes browsing faster.

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

Servers will use the "X-Purpose" 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
"Cache-Control: must-revalidate" 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.

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 "Vary: X-Purpose" responses.  This turns out to not
be the case; a Vary response to prefetches doesn'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
"Cache-Control: must-revalidate" trick above.

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'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't use the
cache-control trick) that you can't attribute user navigation to.  So
network monitoring has strictly more information.

Eric Seidel, in the X-Purpose bug, asked why we'd tag prefetch motivated
requests, when we don't, for instance, tag iframe or XMLHttpRequest
motivated requests.  I think the difference here is that there'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 & 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.

Maciej last week suggested he'd get back to us and explain the motivations
that the Safari team used for adding "X-Purpose: preview", in case they were
helpful here.  He hasn't yet, but I'm sure I'd appreciate hearing about
that!

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

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!

- Gavin

[1] Unfortunately, such servers are losing some of the benefit of
prefetching since there's at least one critical-path RTT, and possibly two
(if no warm TCP connection is available) for these kinds of validated
navigations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20101008/acac245c/attachment.html>