Comments on: Who’s idea was it to remove file extensions from URLs?

By: Angelina

Angelina — Mon, 01 Dec 2008 09:26:31 +0000

Nice work and its helpful for me coz i was finding the same solution.
Regards.

By: Justin

Justin — Fri, 27 Jun 2008 21:31:09 +0000

You’re correct about .php, .aspx, etc. being poor file extensions on URLs, but not having any file extension is just fine as long as the mime-type is set properly. Why should the URL convey metadata about the file type when there’s a HTTP header for that?

By: jaisen

jaisen — Fri, 27 Jun 2008 18:53:09 +0000

@Binny,

I concur. I’m a fan of case sensitivity but it rarely (if ever) benefits the end user.

Case sensitivity can be a tricky problem. As you stated it is a byproduct of the underlying OS. However, it’s also a byproduct of having a hard mapping between URL and file system. This isn’t bad in itself but it’s become so easy to work around what I consider a limitation.

By: jaisen

jaisen — Fri, 27 Jun 2008 18:44:55 +0000

@Benedict,
The proposal is simply to raise awareness of how/when/why using more descriptive file extensions provide an overall benefit. The reason I said mime types are not suitable is, for example, the web browser does not honor that when you try to save a web page. It does not (and probably should not) try to mediate the proper file extension.

Basically, it’s confusing to a user when they save a web page to their computer then later try to open it and are asked what program to use.

By: Binny V A

Binny V A — Fri, 27 Jun 2008 17:55:24 +0000

While we are on the topic of URLs, here is one my pet complains about URL - Case Sensitivity in URLs

By: Benedict

Benedict — Fri, 27 Jun 2008 17:22:45 +0000

You’re certainly correct in saying extension have been abused. But I don’t understand your proposal.

There’s a difference between URI’s and URL’s. URI are more flexible, and preferable. URL’s are tied to a specific representation of the data at a given URI.

Why aren’t mime types a suitable alternative?

By: jaisen

jaisen — Fri, 27 Jun 2008 15:42:53 +0000

@Mark

Good point but I don’t see the harm in assuming the most relevant representation. The default representation can be changed at any time which may or may not render the file extension as an accurate representation for the content. Are you suggesting to completely sever the two?

I don’t think we would ever reach 100% compliance with this but it could generally be a benefit for the majority of cases. There will always be edge cases…but I don’t think that should necessarily keep us from making more sense of the web.

By: Mark

Mark — Fri, 27 Jun 2008 09:49:54 +0000

A URL does not always represent a specific file type, but rather a resource which can be represented in multiple types:

“A resource is a conceptual entity identified by a URI (RFC 2396). An HTTP server like Apache provides access to representations of the resource(s) within its namespace, with each representation in the form of a sequence of bytes with a defined media type, character set, encoding, etc. Each resource may be associated with zero, one, or more than one representation at any given time. If multiple representations are available, the resource is referred to as negotiable and each of its representations is termed a variant. The ways in which the variants for a negotiable resource vary are called the dimensions of negotiation.” - http://httpd.apache.org/docs/1.3/content-negotiation.html

If we later changed the default representation or added a different representation for matching the user’s accept headers, then you’re now serving a file that has a different ‘extension’ to the URL you’re requesting. You say its all about the content, but what you’re suggesting is that we tie the content and the representation of that content together.