This is an example of how I use ForceType. It may not be a fix for
you, but you never know.
<Files *>
ForceType application/x-httpd-php
</Files>
<Files *\.*>
ForceType None
</Files>
This will catch all files without an extension and process them as
PHP. Then all files with an extension will be processed as normal. My
guess is any file with a '.' in the name will also get caught, but
then again, I'm the one uploading files to my server, and I know that
:]
On Wed, Jan 21, 2015 at 3:09 AM, Curry, Alan <pacurry@xxxxxxxxxxxxx> wrote:
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|