W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: Unifying & standardizing X-Moz & X-Purpose headers

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 18 Oct 2010 15:00:02 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <A43F0A74-FB45-461F-8A8F-63B830E9B20E@mnot.net>
To: Gavin Peters (蓋文彼德斯) <gavinp@chromium.org>
I think the only really bad/damaging thing here is starting with an "X-" header. 

Please go ahead and write a spec for a Purpose header, and send to this list for review. You'll need to register the header itself (see RFC3864), and probably set up a small registry for the values, unless you're confident it's a closed set, or perhaps use URLs for extensibility...


P.S. The possibility of
  Vary: Purpose
is an interesting one, but I can't decide if it's actually bad.

On 12/10/2010, at 8:20 AM, Gavin Peters (蓋文彼德斯) wrote:

> Folks,
> Since I sent out the belowquoted proposal, I have written and landed a WebKit patch that implements "X-Purpose: prefetch" for WebKit based browsers that use content prefetching (link rel=prefetch right now).  This includes Chrome.
> So where can this proposal go from here?  Does anyone think this it is a bad idea to add the "Purpose" HTTP request header?
> How do we move this forward if there is consensus?
> - Gavin
> On 23 September 2010 14:56, Gavin Peters (蓋文彼德斯) <gavinp@chromium.org> wrote:
> Hi,
> I'm experimenting with prefetching in chrome & webkit, and I have some
> concerns I wanted to bring to the attention of the HTTP wg.
> Right now the prefetch feature in Firefox adds a nonstandard header:
>  X-Moz: prefetch
> to requests that originate either from <link> elements or the Link: header.
> Safari generates previews of web pages for its startup page and new
> tab page. =C2=A0The requests that generate that view are a full page load
> - Hide quoted text -
> (javascript is run, subresources are loaded...), and it includes the
> header:
>  X-Purpose: preview
> Chrome dev channel and beta right now include an experimental
> implementation of prefetching, which partially follows on the WebKit
> implementation of prefetching.  The WebKit prefetching actually puts
> no extra headers at all in its requests.
> Some google searching reveals that some webmasters use these request
> headers to do things like 404 prefetching requests (a pretty
> legitimate thing to do), and to serve pages without analytics to
> Safari previews.
> Given that http requests are already happening with these markers, and
> that there's three incompatible & inconsistant practices for
> specifying this activity,
> how should we proceed?  I think it would be best if there was one
> header for conveying purposes such as prefetch, preview, etc....
> Immediately, I think a variation on the Safari practice, and a header
> such as:
>  Purpose: preview
> or
>  Purpose: prefetch
> Is likely to best serve everybody's interest.
> Do we agree that this is a useful thing to specify, and if so, what is
> the best way to proceed if we agree?
> - Gavin

Mark Nottingham   http://www.mnot.net/
Received on Monday, 18 October 2010 04:00:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:55 UTC