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

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...

Cheers,

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