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

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

From: Adam Barth <w3c@adambarth.com>
Date: Sun, 17 Oct 2010 21:03:35 -0700
Message-ID: <AANLkTimF1FjVEu-ZsMTi8Lef=iXiptMVPMigQ2_gaC2V@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Gavin Peters (蓋文彼德斯) <gavinp@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>
2010/10/17 Mark Nottingham <mnot@mnot.net>:
> 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.

It kind of defeats the purpose of Purpose: prefetch.  :)

Adam


> 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:04:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:29 GMT