Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"X-" deprecated for HTTP headers

tools.ietf.org

Post reply on HN
Print view View original

11–20 of 39 posts

Re: "X-" deprecated for HTTP headers

#11

Post by krakensden »

raldi wrote: post #9
Jach wrote: post #8

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 cou…

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

Re: "X-" deprecated for HTTP headers

#12

Post by lloeki »

natrius wrote: post #6

Next stop: CSS vendor prefixes.

Not.

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

Like:

    -webkit-gradient(,  [, ]?,  [, ]? [, ]*)
vs:

    -moz-linear-gradient([ [ [top | bottom] || [left | right] ],]? [, ]+);
which eventually became:

    linear-gradient( [ [  | to  ,]?  [, ]+ )
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).

Re: "X-" deprecated for HTTP headers

#13

Post by 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.

Re: "X-" deprecated for HTTP headers

#14

Post by 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.

Re: "X-" deprecated for HTTP headers

#15

Post by regularfry »

lloeki wrote: post #12
natrius wrote: post #6

Next stop: CSS vendor prefixes.

Not. How would you handle the case of pre-standard implementations? Like: -webkit-gradient( , [, ]?, [, ]? [, ]*) vs: -moz-linear-gradient([ [ [top | bottom] || [left | right] ],]? [, ]+); which eventually became: linear-gradient( [ [ | to ,]? [, ]+ ) 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. CS…

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.

Re: "X-" deprecated for HTTP headers

#17

Post by judofyr »

lloeki wrote: post #12
natrius wrote: post #6

Next stop: CSS vendor prefixes.

Not. How would you handle the case of pre-standard implementations? Like: -webkit-gradient( , [, ]?, [, ]? [, ]*) vs: -moz-linear-gradient([ [ [top | bottom] || [left | right] ],]? [, ]+); which eventually became: linear-gradient( [ [ | to ,]? [, ]+ ) 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. CS…

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.

Re: "X-" deprecated for HTTP headers

#18

Post by andrewaylett »

firlefans wrote: post #13

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.i…

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.

Re: "X-" deprecated for HTTP headers

#19

Post by 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.

Post reply on HN