January 9, 2004
I hate Apache's text/plain crap
It's finally happened. IE's "we know better than the server" attitude combined with Apache's "we will ship a known-bad config file by default, since all Apache server users should make the same change to it and will be forced to by all clients perfectly implementing HTTP" attitude have made it quite impossible for a modern browser to always trust the Content-Type provided by the HTTP server. Congrats, Apache team, on a job well done. At least IE's behavior can be somewhat understood in light of Postel's "be liberal in what you accept, and conservative in what you send" doctrine; Apache has no such excuse.
Posted by bzbarsky at January 9, 2004 6:19 PM
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.
> 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.
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.