Subscribe to
Posts
Comments
NSLog(); Header Image

QotD: URL Pet Peeves

Question: What are your URL pet peeves, if you have any?

My Answer: I hate it when "www" doesn't work. For example, http://adobe.com/ didn't work for the longest time (it does today, at least, by forwarding to www.). I don't care for dashes, but I don't know that it's a real "peeve" of mine. I do like common-sense bookmarks, and Amazon.com takes some doing here - they tack on a bunch of metadata that makes it tough to show someone what you're looking at. Speaking of which, here's another peeve (the Apple Store is guilty of this sometimes): URLs that include session IDs. Keep those in the POST or something - let me copy and paste a URL to send to my mother so she can buy the right darn thing without calling me to ask what the URL should have pointed to!

You are encouraged to answer the Question of the Day for yourself in the comments or on your blog.

6 Responses to "QotD: URL Pet Peeves"

  1. The 'www' thing must be my top peeve on URLs. Here in Norway it's so bad that a lot of people wonders if "that's it, no www?" when you try to spell out a URL for them. And of course it annoys me a lot when trying to access a site I've never visited before by typing in their company name or so, just to find out I have to tag on www. to get somewhere.

    The worst cases of this even displays two totally different sites with and without http://www... Talk about bad hosting providers!

  2. I don't like it when slash-delimited hierarchy is underused in favor of passing a bunch of variables to a script with a GET query string, or when it's just underused in favor of throwing a lot of HTML documents into the server root.

    I also don't like the converse, when people refuse to use query variables, and use awkward slash-hierarchy even when it's not really part of a resource hierarchy. (Underusing it is much more widespread, because too many people fail to realize that URLs don't have to correspond directly to filesystem paths. But when they do realize this, they often misunderstand how slash-delimited hierarchy and query strings complement each other, resulting in the latter problem.)

    And I'm also not fond of filename extensions. They're unnecessary, and in any good web server (Apache included) they're easy to remove, so what's the problem?

    I don't like when people misuse HTTP methods. A GET request shouldn't cause a permanent change in any data or metadata about a given resource (consider bash.org's voting system for example). That's the whole point of POST, and it has practical problems also -- especially that doing things like that with GET is just asking for trouble from search spiders and pre-caching proxies. A few simple Google searches prove this: Google has voted positively on 883 bash.org quotes, negatively on 853, and has requested the deletion of 1220. And, even more inconveniently for bash.org, these are in Google's index, so they'll probably all be requested many more times. If they hadn't been lazy by making those commands be stateless GET URLs, this wouldn't be a problem.

    Sometimes POST is also misused. Thankfully, this is rare, but some web designers get the idiotic idea that people should only be able to start viewing their site from the front page, and that nobody should be able to link to anything but the front page, so they program it to use navigation through forms and POST. I don't know what would drive them to commit such Web-thwarting depravities, but those designers will be lucky if I ever go back to any of their sites. This is similar to sites that use incomprehensible URLs containing session IDs, like Amazon and the Apple store, making linking hard or impossible; unfortunately, in such high-profile cases, it's not easy to avoid using such sites at one time or another.

  3. File extensions (.html, .php, etc.) in URLs to main content. What's the point?

  4. 1- when http://www.foo.com explicitly forwards to http://www.foo.com/index.html (Um... WHY?)

    2- when people give out URLs as "visit us online at foo.com," when "foo.com" doesn't work. (This is similar to yours.)

    3- Static URLs that don't end in / (that is, ones that specify a filename), but this really only bothers me if it's the main URL -see #1.

  5. The fact that an entire software application development field (the one that I work in) has become dependent on a framework that was never really designed to support the building of applications in the first place. URIs are great for describing the address of a resource. Although software developers have hacked around and encapsulated them to death, they're still not so great as the backbone of a software application.

    Btw, I agree about the session IDs in the URI (see my para above), but most of the time the request being sent isn't POST so that's not an option. If someone disables their cookies, then the application server has no choice but to attempt to propagate the session through the GET requests. (I don't think it is appropriate to make every link in a web store trigger a POST request simply to avoid putting the session ID in the URI.)

  6. I've written about this before… a Web site configured such that "www" doesn't work. Today I found another: http://edinboro.edu/ times out while http://www.edinboro.edu/ works quickly. Silly! FWIW, I hate "www." I think it's redundant and useless...