Three Monkeys, Three Typewriters, Two Days

If apache has absolutely NO hint as to what the mime type is (i.e. the file has no extension such as .html or .gif - which are recognzied by default) the server will resort to text/plain. This is very much in the spirit of the standard.

In virtually all normal static file situations there will be some sort of hint; i.e. the file will be called foo.gif, or bar.html. If that is not the case, caveat emperor.

With respect to the above - another mirrored rant is possible with respect to the charset for those not using the english/latin-1 charset.

The fact that apache is sending data out as text/plain can be seen as a fairly strict interpretation in 'be strict on what you send'. Other choises could have been 'application/data' - which would possibly have only made the problem described worse; and it would certainly collide with the 'least surprize the user dogma'.

Note that your suggestion; text/html is not that ideal a choise either; as there are quite a few situations where it makes the world less safe: see http://httpd.apache.org/info/css-security/apache_specific.html for more details. Bear in mind that in CSS a innocent bystander is 'abused'. And someone who is not able to ensure that mime types are correct may very likely not understand the subtleties of the CSS.

So yes - thanks to IE we have a hard problem here - and no easy answers.

Dw

> In virtually all normal static file situations
> there will be some sort of hint;

Clearly you're not aware of all the .wmv, .dmg, etc files that Apache happily sends as text/plain.

> Note that your suggestion; text/html is not that
> ideal a choise either

Where did I suggest text/html? My suggestion if you don't know the type is application/octet-stream, which exists for that very purpose. From a browser implementor's viewpoint, it would be even better if Apache just sent nothing at all if it has no idea (which is fully compliant with HTTP/1.1).

> And it would certainly collide with the 'least
> surprize the user dogma'.

I think sending obviously binary data as text/plain clearly collides with the "least surprise the user" dogma, my friend.

Of course; it is aPATCHey server - instead of spending brain cycles on ranting - one could of course set out to make the world a slightly better place"

Instructions are at:
http://www.apache.org/dev/contributors.html#patches

Previously energy and people actively schratching their own itches in this area have a history of leading to positive things; such as the rather Magical http://httpd.apache.org/docs/mod/mod_mime_magic.html.

:-)

Dw

I did submit a patch that would fix this problem, as you would know if you took a look at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13986 (which I mentioned in my mail to you). The patch was rejected, with claims that this patch (which worked, in the testing I have done since) would break various extensions to Apache and that significant rearchitecting would need to happen to implement what I view as the proper behavior without breaking backwards compat.

Now I'm not in the position of having the brain-cycles to significantly rearchitect Apache while at the same time continuing my work on projects that I actually care about.

Further, the change to send application/octet-stream by default (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14095) is a one-liner which anyone who can open a text editor can create the patch for. The issue is whether that patch would be accepted. The moment I get the impression that such an approach would come even close to being accepted, I will post such a patch.

The reason I'm rather upset about this issue is that I've seen a lot of effort on the part of Apache folks to deny the fact that a problem exists, blame IE, blame web server maintainers, etc. Now all are at fault here, but that does not mean that one shouldn't take steps to be less at fault if possible. Frankly, the handling of http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14095 sickens me and does not suggest that if I were to post a patch for http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13986 the patch would even be considered.

So here I am, pointing out that IE is admitting that it's behavior is wrong and leads to problems and is working to change it, while Apache buries its head in the sand and refuses to acknowledge that they are contributing to the problem. The irony would cause me to laugh if I weren't crying.