W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2009

Re: [W3C BPWG] HTTP header fields X-* and normal ones / question

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 21 Jan 2009 11:55:04 -0800
Message-Id: <256EC398-22D3-48B3-A293-E4BB91926E22@gbiv.com>
Cc: <ietf-http-wg@w3.org>
To: <eduardo.casais@areppim.com> <eduardo.casais@areppim.com>

On Jan 21, 2009, at 6:10 AM, <eduardo.casais@areppim.com>  
<eduardo.casais@areppim.com> wrote:
> I am writing on behalf of the W3C Mobile Web Best Practice Working  
> Group
> (W3C
> BPWG).
>
>
> 1) Context.
>
> The W3C BPWG is currently elaborating guidelines for content  
> transformation
> proxies, i.e. proxies that modify HTTP requests sent by terminals and
> responses
> returned by application servers; the paramount case is transforming  
> WWW
> sites
> intended for desktops in a format suitable for mobile devices, notably
> mobile
> phones.
>
>
> 2) Issue.
>
> Some content transformation proxies modify the HTTP request header,  
> and
> place
> the original information in extra backup header fields. These  
> header fields
> concern the client capabilities. The backup fields are prefixed with
> "X-Device-"
> -- X-Device-User-Agent, X-Device-Accept, X-Device-Accept-Charset, 
> X-Device-Accept-Language, X-Device-Accept-Encoding.

WTF?  That's insane.

> The W3C BPWG is looking into formalizing these backup fields and  
> registering
> them as proper HTTP header fields in the IANA registry according to  
> RFC3864.
> This implies that they be renamed in view of eliminating the X-  
> prefix (for
> instance, Device-Accept instead of X-Device-Accept), since it  
> appears that
> HTTP header fields of the pattern X-... are not allowed to be  
> registered (a
> probable consequence of RFC822).
>
> Because deployed transformation proxies rely upon the backup fields  
> with the
> X-Device- prefix, and all deployed proxies cannot be updated to use  
> new
> field
> names in a "big bang" switch-over, the W3C BPWG is potentially  
> facing a
> migration period where both the old, X-Device- fields, and the  
> newer, e.g.
> Device- fields, may have to coexist.

That's even more insane.  If the request is being rewritten then it  
is not
the same request -- the old request fields should not be sent at all.
The inbound server doesn't care about these values and sure as hell
doesn't want to parse them as part of the request. As such, your  
deployed
proxies are irrelevant.

> 3) Questions to the IETF.
>
> 3.a: What is the IETF procedure, policy, standard, or best practice
> regarding
> the promotion of X- header fields to normal, registered  
> (provisionally or
> permanently) header fields?

Never use them in deployed software. The X-prefix is for private use in
experiments that are NOT EXPOSED TO THE INTERNET.

> 3.b: What is the policy, standard or best practice of the IETF  
> regarding the
> simultaneous deployment and utilization of two sets of header  
> fields, which
> have the same semantics, one comprising fields of the pattern X-  
> and the
> other
> fields of a normal pattern?

There is none.

> 3.c: What is the procedure, policy, standard or best practice of  
> the IETF
> regarding the deprecation and discontinuance of HTTP header fields?

Just stop using them.  In this case, there is no reason to send
any such header fields, so just remove them from your specs and
your implementations and you are done.


Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>
Received on Wednesday, 21 January 2009 19:56:48 GMT

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