mnot’s blog

Design depends largely on constraints.” — Charles Eames

Wednesday, 18 February 2009

Stop it with the X- Already!

Filed under: HTTP Protocol Design Standards Web

UPDATE: RFC6648 is now the official word on this topic.

Sometimes, it seems like every time somebody has a great idea for a new HTTP header, media type, or pretty much any other protocol element, they do the same thing. Rather than trying to figure out how to fit into how the rest of the world operates, getting adequate review and socialising their proposal, they just stick a bloody X- on the front and ship it.

The IETF has no-one to blame but itself for this situation, of course. X- was a convention designed for experimentation (hence the ‘x’). However, the problem is in transitioning from experimental to production; as soon as your header (or whatever) escapes the lab and has to interoperate with another system, it’s no longer experimental, it’s on the Internet. Oops.

RFC4288 tried to address this situation for media types;

However, with the simplified registration procedures described above for vendor and personal trees, it should rarely, if ever, be necessary to use unregistered experimental types. Therefore, use of both “x-” and “x.” forms is discouraged.

Likewise, RFC3864 makes the same attempt for HTTP and all other message headers, albeit not so explicitly; instead, by setting up a provisional header repository whose procedure consists of sending an e-mail, we hoped that people wouldn’t feel the need to use X-.

Perhaps in vain, unfortunately. Dan points out how Palm has decided to extend HTML;

A widget is declared within your HTML as an empty div with an x-mojo-element attribute.

<div x-mojo-element=”ToggleButton” id=”my-toggle”></div>


Let’s Make it Easy

Because of this, I think we (the standards community ‘we’) need to over-communicate how formats and protocols should be extended, and under what conditions; indeed, this is one of the explicit goals we wrote into the HTTPbis charter. Only then can we justifiably be angry with people who get it wrong.

In the meantime;

  1. If you’re trying to introduce a new HTTP/SMTP/etc. header, the minimum bar is sending an e-mail to get it into the Provisional Header Repository, as per RFC3864.
  2. If you’re trying to introduce a new media type, have a look at RFC4288 and consider the vnd tree.
  3. If you’re trying to extend HTML, talk to the XHTML, HTML5 and Microformats folks about that.

In none of these cases (or, for that matter, any other case) should an “X-” show its ugly little four-armed, dashed self.

A Few Words on URI-Based Extensibility

As Dan says, the TAG has weighed in on the proper way for formats to enable extensibility, using URIs. This is very relevant to the discussions we’re having about the Link header, since one of the goals is to retrofit URI-based extensibility onto the link relation type identifiers, so that people can ground them in a global namespace.

Atom started this practice, and so far, it’s working reasonably well. There may be a couple of bumps on the road; as DeWitt points out, there are an awful lot of bare-word link relations in use in HTML already. As such, I’m suspecting that we’re going to actually have three kinds of relation type identifiers in reality; absolute URIs for well-identified extension relations, “short” registered identifiers for common well-identified relations, and “short” unregistered relations for ad hoc, locally-scoped and uncoordinated extension relations.

Also, I’d be remiss if I didn’t point out that too much extensibility can be anti-social. Which is why it’s not only necessary how to extend something, but when not to. Otherwise, everyone will be talking past each other using their own proprietary languages.


Rob Sayre said:

How about “X-“ means that people can (will?) overwrite you. LGTM :)

Wednesday, February 18 2009 at 3:01 AM

Jess Austin said:

Sorry if this is an ill-informed question, but what about compatibility with existing systems? Although they probably shouldn’t, I can imagine that some proxies and user agents could puke on unknown headers even while they properly ignore unknown X-headers.

Wednesday, February 18 2009 at 4:23 AM

DeWitt Clinton said:

I even found a large number of URIs used as rel values a little further down in that list.

At first I was excited, thinking that people were really using URIs as an extensibility mechanism. But after a second look all the examples appeared semi-random, like misplaced ‘href’ attributes, or spammy.

I’ll take a closer look to see if anyone is using a URI in the top 100 or so values for a legitimate purpose.

Wednesday, February 18 2009 at 4:36 AM

Subbu Allamaraju said:

AFAIR, Dojo was one of the earliest widget framework that extended HTML with the addition of the dojoType attribute. They could have used the class attribute as an extension point, of course.

Wednesday, February 18 2009 at 4:36 AM

Julian Reschke said:

In related news:

“Since the Atom Publishing Protocol specification was finalized, we have been working on making the Google Data APIs compliant with the AtomPub standard. As of today, we are releasing a new version of most of our services that achieves full compliancy with RFC 5023.

If you’re worried that this may break your current application, rest easy. This change will only be available in API version 2 and higher. If you are happy with the current version, you can keep doing what you’ve been doing and the API will continue to work as it always has. If instead you’d like to use the AtomPub compliant version (and the new v2 features), just specify API version 2 in an HTTP header, and you’re good to go.”

And the new HTTP header is: “GDATA-Version”.

Oh well.

Wednesday, February 18 2009 at 7:09 AM

Nick Lothian said:

For further weird extension examples see

Wednesday, February 18 2009 at 7:38 AM

Kris Zyp said:

OK, I tried registering our headers and the email bounces back: Diagnostic-Code: SMTP; 550 5.1.1 : Recipient address rejected: User unknown in virtual

How do you actually send an email to register provisional headers?

Thursday, February 19 2009 at 2:49 AM

Max said:

I doubt anyone will want to go through a lengthy and risky process (it could be rejected) just to add a small extension. I don’t know why they should even be expected to go through the process in the first place.

Thursday, February 19 2009 at 5:40 AM

Anonymouse said:

I think I’m going to start adding in ‘X-Men: ‘ and ‘X-Wife: ‘ headers to all my pages…

Thursday, February 19 2009 at 8:54 AM

Julian Reschke said:

Kris: could you supply some context? Whom did you try to email?

Max: for the provisional registry, a simple email should be sufficient. See RFC 3864.

Best regards, Julian

Thursday, February 19 2009 at 8:55 AM

John Haugeland said:

You know, the X- actually means something. It’s not just there to annoy you. It means that this is a header which the application uses despite not having RFC ratification.

Please don’t gripe about things you don’t understand.

Thursday, February 19 2009 at 9:08 AM

Kris Zyp said:

@Julian: I figured it out, I guess I had to subscribe to the list before I could send the email.

@Mark: Do you think there are ever any situations where an X- prefixed header is preferred or should we register every header, regardless of how application-specific metadata might be?

Thursday, February 19 2009 at 9:20 AM

Mark Baker said:

I’m gonna disagree about “x-“ because I’m in that kind of mood.

I wish it weren’t a convention once-upon-a-time, but it was and some people seem to like it using it today for whatever reason. But worst case it’s simply aesthetically unpleasing, or perhaps 2 extra octets on the wire, and while I’m all for some “you don’t need to do this” text someplace, it really doesn’t matter very much.

Thursday, February 19 2009 at 9:33 AM

Roy T. Fielding said:

I’ve been arguing against the use of the “x-“ prefix on the Web for ages (well, since early 1994). It has come up in the discussion of HTTP media types, HTML link relations, HTTP content codings, and just about every extension proposed for HTTP/1.1. Search for “Roy T. Fielding” X- prefix.

I wonder if we can get away with adding a general note against the use of such names in HTTPbis? I wasn’t able to do so in 1995, since the email folks objected, but maybe that lesson has been learned by now.

Thursday, February 19 2009 at 11:12 AM

Creative Commons