One thing that's always bugged me is file extensions...I hate having to type ".php" or ".cgi" or ".asp" or whatever else just happens to reflect the server's implementation at the time. If they switch from Microsoft to LAMP then their URLs will probably all break needlessly.
It can be much worse though...exposing machine names, unnecessary complexity and parameters, all changing from year to year.
A server doesn't have to puke its implementation details everywhere. I can't even count all the "enterprise" apps that make that mistake (e.g. a helpdesk system that gives me "serverNameThatWillChangeNextYear.domain.net/some/unnecessarily/convoluted/path.unnecessaryExtension?whatthehellisallthis&garbage1=a&garbage2=b&finallyRelevantBugNumber" instead of a stable URL like "company.net/bugs/bug123456". And just try E-mailing a complex URL to somebody (it wraps, and time is spent to awkwardly correct it).
Honestly, it's as if most web developers don't understand how powerful URLs can be. If you make URLs short and stable and use them to help look up stuff, they can be very nice. Instead in the past I've seen people E-mailing 9-step instructions on how to find something because the damn URL is unreliable.
> Honestly, it's as if most web developers don't understand how powerful URLs can be.
Or, more likely, most of the "enterprise" apps with those URLs were first released over a decade ago, when the idea of "pretty URLs" was not yet mainstream. There was not even a mention of mod_rewrite on Wikipedia at that point. The article on the front controller pattern, which most webapps that handle their own URL routing use, wasn't written until 2008.
> most of the "enterprise" apps with those URLs were first released over a decade ago, when the idea of "pretty URLs" was not yet mainstream.
Or, even more likely, the enterprise customer never specified "URLs that aren't terrible" in their 100-page RFP, and so the lowest bidder didn't bother with URLs that aren't terrible.
The thing that drives me up the wall is "index.html" - that's pretty much inexcusable in my opinion. There are even some sites where the root path on the domain REDIRECTS to example.com/index.html - don't do that.
<a href="/x/"> will work, but will break when someone decides to move "/x" to "/y".
<a href="."> will work from the server, which does an internal redirect, but not on the static version on my local drive I'm going to demo to my boss. (I also have a hunch a significant number of developers aren't aware of "." and don't know this is an option.)
So we end up with <a href="index.html"> for better or worse.
If you're having problems like this, your web development environment is total garbage and should be fixed.
99% of the time the reason for index.html is the developer was viewing static files in their browser because they didn't have a proper server or test environment. This is inexcusable in 2012.
The index object should be the default page opened by a webserver for any given unspecified path.
Eg: http://www.example.com/path/to/url/ should open to the first specified of the the specified default objects, typically index.html index.shtml index.php index.php, or similar. This is defined in your Apache conf file, or locally via .htaccess.
I understand that: index.html is just one possible name for the "default page" filename. IMO its perfectly valid (if redundant) to specify it explicitly in a url. I still don't understand why this was described (not by you) as unacceptable.
In general, you want URLs that are short, clear, memorable, and stable. You want to tell people,
"Come to mydomain.com/blog," not,
"Come to http://www.wordpress.mydomain.com/stamp_collectors_heaven_bl... The latter includes lots of information that their browser + your server can figure out, so you shouldn't be burdening your (potential) users with it.
So, regarding the "index.html" portion: The index is the default. There's no point having a default if you have to specify it, and there's no point specifying it if it's the default.
A web page should have one and only one URL. If you link to the index.html version of a page you're creating two URLs for that page (the index.html one and the bare / one). The / one is shorter, easier to type and more attractive, so you should pick that one.
If you'd started with the 'document'-.'html' naming convention, you could use any of numerous webserver hacks to preserve this illusion. How you request something has little to do with what the server does to satisfy your request.
What I was distinguishing earlier was the distinction between 'return default index of this level of the path' and 'return a specific document from this level of the path'. Specifically indicating 'index.html' is a tad gauche.
I think some organizations see this kind of implementation leakage as a feature, not a bug.
I remember when http://microsoft.com/ began doing external redirects to "default.asp" circa 1997. If you were a "webmaster" (do these exist anymore?), this was a dog whistle. They were not using static .html (or .htm) but not any of the common dynamic methods like .cgi or .shtml either. And using "default" rather than "index" indicated a break from NCSA/Apache convention. They were using a different web server. Those 11 extra characters said a lot.
Bright people use other people's problems to their advantage: in pg's viaweb they deliberately put extra `cgi-bin/` every here and there just to confuse their competitors.
Problem ist most companies don't have someone who actually owns the URL namespace. Or the engineer who wrote that bug reporting tool was too shy to contact the CIO, etc.
I agree with your point, but it's also valuable to understand the structural reasons that prevent such things.
If it's bad magic, update your distro. If it's a Konqueror error, file a bug. I'd be surprised if upstream hasn't addressed this (quick DDG/Google doesn't turn up any similar complaints).
But they are zip files. (Though `file somebook.epub tells me "data". Sigh. Desktop and OS seem to be on different pages.)
Just like .css and .log are text files, but I may not want the same default file handler.
What I like is having *.epub open in, say, calibre, but if I append a .zip extension then it will open in xarchive.
Anyways, I open most things from the command line and wrote my version of 'open' so I get what i expect 99% of the time. :)
I'm using KDE3 so I'm not expecting any upstream fixes for this in my lifetime. I can live with crafting my own solutions.
What might work best is if mime types were used by default but forcing behavior for specific extensions was much easier. Get the best of both worlds (which I can mostly do in KDE3 Konqueror but it's tedious.)
File(1) on my Debian wheezy says they're epubs. File has dealt with nested formats for decades. It examines up to the first 1024 bytes of the file IIRC.
Other examples: tar.gz, WAR files, most ODF formats.
Or do you mean storing a database of the application associated, specifically, with any given file (so that I might open, say, a given myprog.c with vi, emacs, or textmate)?
The Mac OS resource fork model attempts the second, but it's an inherently single-user concept that leaves artifacts around for other users and/or on shared media in an annoying way. A shadow filesystem maintained on a per-user basis under their control would be a preferred solution.
Files used to be tied to applications directly. While I prefer the BeOS approach of MIME-type, it's not nearly as user-friendly as a file extension.
OS X tries to hide extensions by default, which like the behavior in Windows that's similar, seems dangerous. Too many times people have been stung by sexy.jpg.exe.
It can be much worse though...exposing machine names, unnecessary complexity and parameters, all changing from year to year.
A server doesn't have to puke its implementation details everywhere. I can't even count all the "enterprise" apps that make that mistake (e.g. a helpdesk system that gives me "serverNameThatWillChangeNextYear.domain.net/some/unnecessarily/convoluted/path.unnecessaryExtension?whatthehellisallthis&garbage1=a&garbage2=b&finallyRelevantBugNumber" instead of a stable URL like "company.net/bugs/bug123456". And just try E-mailing a complex URL to somebody (it wraps, and time is spent to awkwardly correct it).
Honestly, it's as if most web developers don't understand how powerful URLs can be. If you make URLs short and stable and use them to help look up stuff, they can be very nice. Instead in the past I've seen people E-mailing 9-step instructions on how to find something because the damn URL is unreliable.