The 2.4 documentation says: |The DefaultType directive no longer has any effect, other than to emit a |warning if it's used with any value other than none. You need to use |other configuration settings to replace it in 2.4. I am unable to determine what those "other configuration settings" are. The closest thing seems to be ForceType, but according to https://issues.apache.org/bugzilla/show_bug.cgi?id=57313 it is not a substitute. As far as I can tell from the documentation, if I tried to use ForceType as a direct replacement for DefaultType, it would send the same Content-Type for *all* requests, even the ones that have a type which can be determined through the usual rules. What I need is a rule that sets a Content-Type for files whose type is otherwise unknown. Just like DefaultType did in 2.2. Users put files on the server. Any kind of files they like. Other users download those files via httpd. If files of unknown type are served with Content-Type: application/octet-stream, everything is fine. If they're served without a Content-Type header (which is what 2.4 is doing) then Internet Explorer users complain at me because it tries to parse them as HTML. When someone complains, I can look at the filename and add its suffix to the server config. But this will be a perpetually repeating problem, adding types one at a time as they're discovered. There must be some way of permanently fixing this problem that doesn't require me to know in advance every file type that any user might some day upload. I'm slightly worried based on the bug report referenced above that 2.4 may not have a solution to this problem. But it really shouldn't be that way. Sending any response without a Content-Type is a violation of the SHOULD in RFC2616 7.2.1. As such it shouldn't be happening without a good reason. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|