
"X-" deprecated for HTTP headers - michaelfairley
http://tools.ietf.org/html/rfc6648
======
Jach
I was going to make a joke that "X-Subliminal" from <http://tuxgames.com>
should become "com.tuxgames.subliminal", but I see they already made it for
me...

> _In some situations, segregating the parameter name space used in a given
> application protocol can be justified:_

> _1\. When it is extremely unlikely that some parameters will ever be
> standardized. In this case, implementation-specific and private- use
> parameters could at least incorporate the organization's name (e.g.,
> "ExampleInc-foo" or, consistent with [RFC4288], "VND.ExampleInc.foo") or
> primary domain name (e.g., "com.example.foo" or a Uniform Resource
> Identifier [RFC3986] such as "<http://example.com/foo>). In rare cases,
> truly experimental parameters could be given meaningless names such as
> nonsense words, the output of a hash function, or Universally Unique
> Identifiers (UUIDs) [RFC4122]._

~~~
raldi
Could you explain the reference in your first paragraph?

~~~
krakensden
Open tuxgames.com with the Chrome Inspector or Firebug on, and look at the
reply headers. They have an unusual one:

X-Subliminal:You want to buy as many games as you can afford

------
drsim
Hmm... I've worked on software at three different orgs that rely on the
X-Forwarded-For header to identify a client's IP address from in front of a
firewall (I'm not a network guy, but I think it was Cisco equipment).

I agree the X- prefix ain't great. Is there an alternative for the originating
IP address? If not, we need one.

~~~
apgwoz
Well, I guess their hope is that people start using Forwarded-For, and then it
becomes standardized in the same way that X-Forwarded-For has sort of become
standard.

~~~
drsim
Thanks. Draft here: [http://tools.ietf.org/html/draft-ietf-appsawg-http-
forwarded...](http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-04)

------
yaix
Good thing.

Next, please convince browser vendors to support HTTP methods (PUT, DELETE,
etc.) in forms.

~~~
MatthewPhillips
You're probably aware of this, but for those that are not, you can easily get
around this problem by adding a hidden form field with X-HTTP-Method-Override
as the name and the method as the value. Assuming your web server supports the
field.

~~~
MarceloRamos
Awesome, I don't know if I'll ever use it, but it's good to know.

~~~
MatthewPhillips
If you want to build a RESTful website, it's really hard to get around it.
Consider logging out. You want to send a DELETE to /Session. So you can just
do this:

    
    
      <form action="/Session" method="post">
        <input name="X-HTTP-Method-Override" type="hidden" value="DELETE" />
        <input type="submit" value="Log off" />
      </form>

------
natrius
Next stop: CSS vendor prefixes.

~~~
lloeki
Not.

How would you handle the case of pre-standard implementations?

Like:

    
    
        -webkit-gradient(<type>, <point> [, <radius>]?, <point> [, <radius>]? [, <stop>]*)
    

vs:

    
    
        -moz-linear-gradient([ [ [top | bottom] || [left | right] ],]? <color-stop>[, <color-stop>]+);
    

which eventually became:

    
    
        linear-gradient( [ [ <angle> | to <side-or-corner> ,]? <color-stop> [, <color-stop>]+ )
    

In CSS, the vendor prefixes are _exactly_ what we need. They help
bootstrapping, discussing, and proofing standards by having pre-standard
implementations in the wild.

CSS is vastly more complex than HTTP headers which are most of the time, key-
value(s).

~~~
regularfry
You can have pre-standard implementations without vendor prefixes. Here's an
argument against them:

    
    
        http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref.html
    

And here's some further discussion:

    
    
        http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref_1.html
    

Personally I think vendor prefixes are an awful hack. We've already got
browser-conditional comments in HTML, why not use them? Hell, browser-specific
stylesheets would be a better option from where I'm sitting.

~~~
tszming
>> We've already got browser-conditional comments in HTML

You mean the `conditional statements` introduced and only used by IE?

<http://en.wikipedia.org/wiki/Conditional_comment>

~~~
regularfry
Yep. It's a better plan than vendor prefixes.

Edited to clarify: I mean that browser-conditional comments should be
implemented across browsers, not that we should rely on features already
implemented.

------
Sniffnoy
More than just HTTP headers!

------
firlefans
Firstly, I'm only discussing it's application to HTTP and I realise this is a
more general rule. Customer X- headers are a hack, but they're also incredibly
useful for simple debugging ala FirePHP, for transmitting application specific
metadata or caching metadata in dev environments. The RFC even mentions a
similar objection under three 'primary objections to deprecating the "X-"
convention' - BCP 82, <http://tools.ietf.org/html/bcp82>.

Also, this statement, "the name space is not limited or constrained in any
way, so there is no need to assign a block of names for private use or
experimental purposes", this is true only for application/browser vendors
(native devs), web devs are stuck with X- headers for sending custom data to
the browser without interrupting page output.

~~~
andrewaylett
I think the point is more that, instead of using X- headers you should just
declare your header de-facto standard (because you're using it!) and name it
without the "X-". The issue with prefixing headers with "X-" is that, in
theory, when people start using it you've got to remove the "X-" at some point
-- but that would cause all sorts of compatibility headaches.

------
phibit
Does anybody know what the recommended practice is?

~~~
momokatte
It's not just about the prefix -- the goal is to get rid of the unstandardized
parameter namespace entirely. New parameters should be named for permanence,
so if they do become standard there's no need for migration.

<http://tools.ietf.org/id/draft-ietf-appsawg-xdash-05.html>

------
sleepyhead
What is wrong with custom http headers? Like these from Cloudfront:

X-Ua-Compatible: IE=Edge,chrome=1

X-Request-Id: 19c0a05fd28e371127a76f658203eace

X-Runtime: 0.002039

X-Content-Digest: 2c4b5e9fc815a69ecb514e41e27e6ac7f2716801

X-Rack-Cache: miss, store

X-Varnish: 1299462197

X-Cache: Hit from cloudfront

X-Amz-Cf-Id: kDpGVcaIcDVQm-
PkMd_FPnR_IcPZqPgR0NxKEvmOBWKaURpeus5vEw==,_ycCBrLJT91EOYt14GTciFKKLlpzLt1cogvPpK2PkDP7QzYVGbcsGQ==

~~~
jjguy
Appendix B:

    
    
        The primary problem with the "X-" convention is that unstandardized
       parameters have a tendency to leak into the protected space of
       standardized parameters, thus introducing the need for migration from
       the "X-" name to a standardized name.  Migration, in turn, introduces
       interoperability issues (and sometimes security issues) because older
       implementations will support only the "X-" name and newer
       implementations might support only the standardized name.  To
       preserve interoperability, newer implementations simply support the
       "X-" name forever, which means that the unstandardized name has
       become a de facto standard (thus obviating the need for segregation
       of the name space into standardized and unstandardized areas in the
       first place).
    

Most of your examples are covered under the "exception 1" clause, also in
Appendix B:

    
    
       In some situations, segregating the parameter name space used in a
       given application protocol can be justified:
    
       1.  When it is extremely unlikely that some parameters will ever be
           standardized...
       2.  When parameter names might have significant meaning...
       3.  When parameter names need to be very short (e.g., as in [RFC5646]
           for language tags)...

------
mildweed
So, now we in the community need a clearinghouse to declare new HTTP headers.
Let me be the first: Comment.

    
    
      <?php
      header('Comment: some context on why this reply happened');
      ?>

------
saurik
This was also discussed when it was a draft a few months ago.

<https://news.ycombinator.com/item?id=3539663>

------
pacoverdi
I guess django will have to find a replacement for X-CSRFToken

~~~
apgwoz
Yes, CSRFToken.

------
SimHacker
Does this mean X-Windows is finally obsolete?

~~~
astrodust
Technically there's no plural in the "X Window System", X or X11 for short.
(<http://en.wikipedia.org/wiki/X_Window_System>)

Windows is a Microsoft product.

------
jpswade
...and while we're on the subject HTTPD's should return your IP address in
their headers.

This would make IP discovery easy peasy!

------
shasty
I dont know if this will get approved but forcing us all to integrate headers
into HTTP standards is not going to work. Thats why X headers exist.

We need ways to move forward or e ven sideways if thats what we choose using
an extension mechanism that is simple.

