"X-" deprecated for HTTP headers(tools.ietf.org)
tools.ietf.org
"X-" deprecated for HTTP headers
http://tools.ietf.org/html/rfc6648
15 comments
Could you explain the reference in your first paragraph?
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
X-Subliminal:You want to buy as many games as you can afford
[deleted]
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.
I agree the X- prefix ain't great. Is there an alternative for the originating IP address? If not, we need one.
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.
Thanks. Draft here: http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded...
I think the relevant portions are:
> 1. Deprecates the "X-" convention for newly defined parameters (emphasis mine)
> 4. Makes no recommendation as to whether existing "X-" parameters ought to remain in use or be migrated to a format without the "X-"; this is a matter for the creators or maintainers of those parameters.
In practice, I expect X-Forwarded-For to live long and prosper for many years even if a X-less version standardizes.
> 1. Deprecates the "X-" convention for newly defined parameters (emphasis mine)
> 4. Makes no recommendation as to whether existing "X-" parameters ought to remain in use or be migrated to a format without the "X-"; this is a matter for the creators or maintainers of those parameters.
In practice, I expect X-Forwarded-For to live long and prosper for many years even if a X-less version standardizes.
Good thing.
Next, please convince browser vendors to support HTTP methods (PUT, DELETE, etc.) in forms.
Next, please convince browser vendors to support HTTP methods (PUT, DELETE, etc.) in forms.
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.
Awesome, I don't know if I'll ever use it, but it's good to know.
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>Next stop: CSS vendor prefixes.
Not.
How would you handle the case of pre-standard implementations?
Like:
CSS is vastly more complex than HTTP headers which are most of the time, key-value(s).
How would you handle the case of pre-standard implementations?
Like:
-webkit-gradient(<type>, <point> [, <radius>]?, <point> [, <radius>]? [, <stop>]*)
-moz-linear-gradient([ [ [top | bottom] || [left | right] ],]? <color-stop>[, <color-stop>]+);
linear-gradient( [ [ <angle> | to <side-or-corner> ,]? <color-stop> [, <color-stop>]+ )
CSS is vastly more complex than HTTP headers which are most of the time, key-value(s).
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
http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref_1.html
>> 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
You mean the `conditional statements` introduced and only used by IE?
http://en.wikipedia.org/wiki/Conditional_comment
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.
Edited to clarify: I mean that browser-conditional comments should be implemented across browsers, not that we should rely on features already implemented.
vender prefixes are broken. What happens if the same vendor wants to implement another version of the same (still experimental) property?
What we need is draft prefixes. WebKit implements one type of gradient? Great, they define a prefix/property (which could be something as simple/silly as -webkit1-gradient), and anyone who implements the same API is free to use the same property name.
What we need is draft prefixes. WebKit implements one type of gradient? Great, they define a prefix/property (which could be something as simple/silly as -webkit1-gradient), and anyone who implements the same API is free to use the same property name.
In this particular case, handling the pre-standard implementations would have been trivial because they all have different syntax. So you'd just write them all in there, and the ones that don't apply in the UA in question would just fail to parse and get dropped.
A few months ago there was a link to a W3 discussion about this.
http://news.ycombinator.com/item?id=3561950
http://news.ycombinator.com/item?id=3561950
More than just HTTP headers!
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.
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.
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.
Does anybody know what the recommended practice is?
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
http://tools.ietf.org/id/draft-ietf-appsawg-xdash-05.html
[deleted]
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==
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==
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).
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)...They aren't complaining about custom http headers it's just the practise of using "X-" on front of the names.
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');
?>This was also discussed when it was a draft a few months ago.
https://news.ycombinator.com/item?id=3539663
https://news.ycombinator.com/item?id=3539663
[deleted]
Does this mean X-Windows is finally obsolete?
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.
Windows is a Microsoft product.
...and while we're on the subject HTTPD's should return your IP address in their headers.
This would make IP discovery easy peasy!
This would make IP discovery easy peasy!
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.
We need ways to move forward or e ven sideways if thats what we choose using an extension mechanism that is simple.
> 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].