[webkit-dev] X-Purpose on prefetching requests

[Gavin Peters (蓋文彼德斯)]

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