Pages with no file extension?!

How can this be done?

[MatthewHSE]

I read on www.w3c.org that you can actually save your files with no file extension, and still use them on your site. You refer to the file name, something like this . . .

/images/logo

. . . and the server is supposed to choose the file named "logo," regardless of whether it's a jpg or a gif. The same strategy allegedly works with webpages themselves, too.

The advantage, of course, is that you can change your file extensions and still have the result you want without updating all your pages. I can see how that would be handy in many cases; for instance, I just recently learned how to edit my .htaccess file to allow .html files to include SSI's. So if all my links looked like this . . .

mysite.com/aboutme (no extension)

. . . I wouldn't have to update the links even after I change from .shtml files to just .html.

So I thought this sounded pretty great and went to test it out. Of course it didn't work. Apparently there's some sort of server configuration I need to work out. Does anyone else have experience with this scenario?

I'd link to the w3c article, but somehow can't find it now. (It was one of those "tips of the day" that you see when a page validates correctly. A detailed site search at w3c hasn't found the right article yet.)

[tedster]

There's been quite a buzz about this direction recently. The grandaddy of this consideration is Cool URI's Don't Change [w3.org] by Tim Berners-Lee. There's also a nice set of reference links on PixelCharmer [pixelcharmer.com].

[g1smd]

With content negotiation I believe that you still have to upload the files with an extension on the filename. You also have to configure some stuff on the server. The browser does not have to state an extension when requesting a file. More information at: [evolt.org...]

[tedster]

The PixelCharmer link includes the W3C page about Content Negotiation, but it's probably a good idea to list it here as well. Look for Guideline #7, a bit below the half way mark.

W3C on Content Negotiation [w3.org]

[keyplyr]

The articles present Content Negotiation as simple to implement but "rarely used on the Web today." I wonder why?

[MonkeeSage]

Seems to me like document namespace + DOCTYPE + meta content-type would be more than enough info to allow for client side content negotiation (including files w/o extensions)...I dunno why they haven't implementsed it in the browsers yet since they have to parse and validate the DTD anyhow...

Jordan

[g1smd]

But gif and jpg files don't have a DOCTYPE or a meta tag?

[MonkeeSage]

Well, that's true enough...so just go ahead and squish my pipe-dreaming, why don't you, you big ol' meannie. Hehe. ;P

Jordan

[g1smd]

... but they do have an identifier in the first few characters inside the file itself:

JFIF for .jpg

GIF87 or GIF89a for .gif

MZ for .exe

and so on.

[Jingle]

Hi MatthewHSE,

I don't think SSI can direct a non-file-extension request to a specific location with file extension. i.e. mydomain.com/file-a to mydomain.com/file-a.html Actually, I don't know how to set up SSI without file extensions.

If you don't just want to update all the links in your website, you don't need to use SSI; you can forget about file extension, or you can make up an extension.

After making an shtml file, rename it without extension ("file-a.shtml" to just "file-a") or change the extension you like ("file-a.shtml" to "file-a.aaa" .aaa as an example.) When you want to change shtml file to html file, do the same thing after making html file. (rename file-a.html" to "file-a" or "file-a.aaa") Either way, you don't have to update the links.

If all pages were static, everything would work fine. If your site has dynamic pages, it might still works on dynamic pages, but you should test profusely.

[drbrain]

Content negotiation involves the client sending an Accept header, and the server returning the proper alternate from the Client's choice. (there are also Accept-Language, Accept-Encoding, and Accept-Charset headers, among others).

Apache does this by mapping your request for index.html to one of index.html.<language>[.<encoding>], so no MIME types are guessed. Guessing MIME types on the client is an evil thing to do (IE does it).

Mozilla's Accept headers are:

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
text/plain;q=0.8,
video/x-mng,image/png,image/jpeg,image/gif;q=0.2,
*/*;q=0.1

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Linebreaks added to prevent wrap.

[BjarneDM]

The primary problem with content negotiation as I see it is the Accept-Language header. Given that this is a user-defined value how many people do you think remember to set this value *correctly* in their browser? In my experience: none! Thus a danish site might inadvertently serve the english version of the site to the danish audience just because the unknowing and un-educated audience hasn't set the Accept-Language in their browsers to prefer danish. And there'll be *NO* feedback that there're more than one language version available.

Thus, in my opinion, for language it's best to give the user a list of choices and then use session-variables to serve the correct language version of the site

On the other hand, I've successfully content-negotiated based upon the Accept header serving xml to Gecko-based browsers and html to those not understanding xml.

[g1smd]

As I see it, you still need to state the extension on the filename when you actually upload the file though.