I’ve got a mostly written post in support of what I will term the rev=”canonical” movement, but it will have to wait for now.

For background see: Save the Internet with Rev Canonical, and A rev="canonical" HTTP Header

For the moment, the entire movement is moving way too fast. There are problems in the current suggested implementations, people are suggesting solutions (often different ones), that are then getting adopted almost overnight by some rather large sites.

This is foolish.

While I’m all for testing things out, and seeing how they work in the real world, I’m not sure that’s how I would describe what’s happening now. Presently we have standards being suggested on a variety of blogs, then being adopted in a variety of different ways on large sites trying to support the movement.

If this doesn’t slow down very quickly (and it presently looks more like a runaway freight train) at least one of the following will happen:

  • Different sites will implement it differently, and not want to change. There’s no formal standard anyways so why should they move over to the other model. Leaving us programmers to implement like three different solutions.
  • Security problems will become ingrained in the practiced version of the pseudo standard leaving sites unwilling to implement it because of the risks.
  • The final version will be such a hack, that adoption will be permanently crippled because people are unwilling to import such hacky code. Hacky ugly solutions are exactly what you end up with when you’re in a rapid cycle of problem discovery -> instant solution, as opposed to being willing to step back and consider everything at length.
  • A standards body like the W3C will step in, see that there is a problem with the current implementation and standardize on something else. Leaving us with a standard, and a pseudo standard.


I want this to succeed, I just feel that our present speed (as opposed to course) is leading towards disaster. Take a look at PHP and the whole namespace situation. The core team had a nearly completed solution, then threw it away to do better. This was a great decision, short term pain, great results in the end. The PHP team was able to do that because they're… a team. I'm not sure that can happen here, with the variety of people blogging what they think should work in disparate locations, it will be hard for anyone to move backwards, throw stuff away and improve.

Things that would help

  • A centralized location for the discussion, blogs and blog comments are no way to solve real problems
  • A clearly defined problem. Unless you can describe and scope the problem you're trying to solve you can't work or discuss it effectively. If the problem included language like "URLs greater than 40/25/15/10 characters can be problematic, the goal is to allow content to suggest a URL under this length" we would at least know what we were aiming for.
  • A grace period between suggestions and adoption. Developers hate re-writing code, if things were set in stone for even a few days before people raced out and did it, those few days would give researchers and tinkerers an opportunity to come up with solutions to not-yet-live problems, as opposed to live ones.

Comments »

No Trackbacks
I don't think you have to worry about early adopters. This is as easy to change as it is to implement. (Very easy.)

I think the standards groups are more reasonable than people give them credit for, although like any group of people, there are those who can give a bad impression. Generally speaking, I think they're interested in offering guidance and documenting usage to help promote consistency.

There's an API people can implement, so that if a different rel value is chosen, you won't have to change any code at all:

http://revcanonical.appspot.com/api?url=http://shiflett.org/articles/cross-site-request-forgeries
#1 Chris Shiflett (Homepage) on 2009-04-16 17:14 (Reply)

While changing from one quick hack to another is generally quite easy. You're going to break backwards compatability (screwing over everyone still on the old version).

Maintaining backwards compatability which changing from quick hacks is rarely so easy.
#2 Paul Reinheimer (Homepage) on 2009-04-16 17:33 (Reply)

Which is probably why the people who initiated this are just waiting for the dust to settle to see whether there's any reason to change. So far, none of the arguments against have been very convincing, so it may remain, but I'm sure everything will be taken into consideration.

If people just implement the API, it won't matter too much.
#3 Chris Shiflett (Homepage) on 2009-04-16 17:37 (Reply)

Let them run wild. With their efforts, hopefully we find the best solution.

Why not make a site just for this one thing? Would sort of be like a Sitemaps.org - with a forum. =)
#4 EllisGL on 2009-04-16 17:41 (Reply)

Exactly the point I was trying to make to this guy on http://tweader.com/conversation.php?id=1532400065

I like the idea, don't mind what standard they eventually settle on, as long as the revcanonical API gets updated I'm all good.
#5 Dave Marshall (Homepage) on 2009-04-17 11:19 (Reply)

+1

It's scary how fast this thing is moving and the fact that some major sites had no qualms messing with canonical URLs en-masse on production systems on a holiday weekend sends shudders down my spine. A single character typo (rel instead of rev) could permanently destroy a site like Ars Technica's search engine positioning and do untold damage, which for me is reason enough to drop rev=canonical.

The only reason I can think that self-proclaimed security experts like Chris Shiflett (who for someone "without a dog in this fight" was remarkably quick to respond) is for bragging rights for "saving the Internet" (his own words). That's lame and either extremely stupid, stubborn or both.

shortlink is a sensible option that I hope these guys will accept... it's documented, implemented and is going through the usual standards processes (it's up for discussion on the IETF's apps-discuss list as we speak and hasn't been comprehensively shot down like rev=canonical, plus it doesn't incite rampant confusion as short_url does).

Sam
#6 Sam Johnston (Homepage) on 2009-04-19 20:15 (Reply)


Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
 

Hi, I’m Paul Reinheimer, a developer working on the web.

I co-founded WonderProxy which provides access to over 200 proxies around the world to enable testing of geoip sensitive applications. We've since expanded to offer more granular tooling through Where's it Up

My hobbies are cycling, photography, travel, and engaging Allison Moore in intelligent discourse. I frequently write about PHP and other related technologies.

Search