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

From: Gavin Peters (蓋文彼德斯) <[email-masked]>
Date: Mon, 11 Oct 2010 17:20:43 -0400

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 (蓋文彼德斯) <[email-masked]>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
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 12 Oct 2010 08:30:16 +0200

On 11.10.2010 23:20, Gavin Peters (蓋文彼德斯) wrote:
> 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?
>
> ...

Write a spec?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Oct 2010 15:00:02 +1100

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?
> 
> On 23 September 2010 14:56, Gavin Peters (蓋文彼德斯) <[email-masked]> wrote:
> Hi,
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: Adam Barth <[email-masked]>
Date: Sun, 17 Oct 2010 21:03:35 -0700

> is an interesting one, but I can't decide if it's actually bad.

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

Adam

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Oct 2010 15:05:02 +1100

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

Probably, but I wouldn't be surprised if somebody came up with some really weird use case.

Cheers,

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 17 Oct 2010 06:39:42 +0100

>> How do we move this forward if there is consensus?

+1.

-- 
IETF Application Area Director, <http://www.ietf.org/iesg/members.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 18 Oct 2010 08:05:32 +0100

>I think the only really bad/damaging thing here is starting with an "X-" header.
Maybe it is time to deprecate the X- convention, as it doesn't seem to 
be working.

---

From: Adam Barth <[email-masked]>
Date: Mon, 18 Oct 2010 00:48:51 -0700

On Mon, Oct 18, 2010 at 12:05 AM, Alexey Melnikov
<[email-masked]> wrote:
> Maybe it is time to deprecate the X- convention, as it doesn't seem to be
> working.

Okiedokes:

https://bugs.webkit.org/show_bug.cgi?id=47802

Adam

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 18 Oct 2010 09:16:08 +0100

>https://bugs.webkit.org/show_bug.cgi?id=47802
Hi Adam,
I think you've misunderstood my comment. I don't think that headers 
starting with "X-" should be treated specially. Historically many X-* 
headers got widely deployed, at which point renaming them doesn't really 
work. That why I said "to deprecate X- convention".

If one want to use a new header field, than using something without X- 
might be better.

In this particular case, if X-Purpose is already deployed, it is 
probably Ok to leave it be as is. However if changing to "Purpose" can 
be done at this stage without much backward compatibility problems, than 
that should be done.

Regards,
Alexey

P.S. This is my personal opinion, HTTPBIS WG or email experts might have 
other opinions on the subject. So consensus is yet to be reached.

---

From: "Eric J. Bowman" <[email-masked]>
Date: Mon, 18 Oct 2010 02:26:50 -0600

Alexey Melnikov wrote:
> Maybe it is time to deprecate the X- convention, as it doesn't seem
> to be working.
> 

"In the future, more top-level types may be defined only by a
standards-track extension to this standard. If another top-level type
is to be used for any reason, it must be given a name starting with
"X-" to indicate its non-standard status and to avoid a potential
conflict with a future official name."

http://tools.ietf.org/html/rfc2045

It's RFC 2045 you'd need to change, not HTTP...

-Eric

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 Oct 2010 10:27:23 +0200

> other opinions on the subject. So consensus is yet to be reached.

I agree that something should be done wrt "x-".

But, as far as I can tell, "X-Purpose" is not widely deployed, so let's 
try to get this one right.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Oct 2010 19:34:44 +1100

RFC2045 doesn't define HTTP headers.

---

From: "Eric J. Bowman" <[email-masked]>
Date: Mon, 18 Oct 2010 03:14:23 -0600

The only place I see 'X-' defined is in MIME, not HTTP, so how can
HTTPbis deprecate it?  I thought HTTP header definitions qualified as
"standards-track extensions to this standard," i.e. HTTP headers are a
profile of MIME headers where there's overlap, where there's none it's
an HTTP MIME header, whereas X- implies "not MIME".  Not so?

-Eric

Mark Nottingham wrote:
> > standards-track extension to this standard. If another top-level
> > type is to be used for any reason, it must be given a name starting
> > with "X-" to indicate its non-standard status and to avoid a
> > potential conflict with a future official name."
> >

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 18 Oct 2010 11:22:03 -0600

> Maybe it is time to deprecate the X- convention, as it doesn't seem to

https://datatracker.ietf.org/doc/draft-saintandre-xdash-considered-harmful/

I'll work to push out -01 before next Monday's deadline.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/