Mailing List Archive

What replaces DefaultType in 2.4?
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@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: What replaces DefaultType in 2.4? [ In reply to ]
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@tsc.k12.in.us> 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@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: What replaces DefaultType in 2.4? [ In reply to ]
On Tue, Jan 20, 2015 at 11:09 AM, Curry, Alan <pacurry@tsc.k12.in.us> wrote:
> 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.

RFC7231 obsoletes 2616 and drops this recommendation. The general idea
is that instead of defaulting, omit it so browsers can sniff a
content-type when they absolutely have to (and not have to
second-guess other content-types by sniffing). I think the idea of a
default content-type is considered harmful for the server/browser
ecosystem.

(The author of RFC2616, RFC7321, and the patch no-op'ing DefaultType
are all the same person)



--
Eric Covener
covener@gmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
RE: What replaces DefaultType in 2.4? [ In reply to ]
Eric Covener [covener@gmail.com] wrote:

> On Tue, Jan 20, 2015 at 11:09 AM, Curry, Alan <pacurry@tsc.k12.in.us> wrote:
> > 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.
>
> RFC7231 obsoletes 2616 and drops this recommendation. The general idea
> is that instead of defaulting, omit it so browsers can sniff a
> content-type when they absolutely have to (and not have to
> second-guess other content-types by sniffing). I think the idea of a
> default content-type is considered harmful for the server/browser
> ecosystem.

Thanks for pointing that out, I'll have to read that updated RFC soon. But I
don't immediately see the point in the change. What does "missing Content-Type"
do that "Content-Type: application/octet-stream" didn't do already? They both
give the client no information about the file type; the only difference I see is
that one of them is interoperable with Internet Explorer and the other one isn't.

Anyway, regardless of the theory, the loss of DefaultType has had a severely
negative impact on some of my users, I'm not allowed to tell them to take their
MSIE and shove it, so it needs to be fixed somehow.

It seems like I should be able to do it with the Header directive like this:

Header setifempty Content-Type application/octet-stream

but when I tried that, all responses became application/octet-stream. Somehow
the setifempty didn't work. Then I found a suggestion here:

http://serverfault.com/questions/520477/set-header-in-apache-if-it-doesnt-already-exist

which looked like it should apply with some slight modification:

Header set Content-Type application/octet-stream expr="resp('Content-Type')==''"

but that just gave me a parse error:

Can't parse envclause/expression: syntax error, unexpected $end

>
> (The author of RFC2616, RFC7321, and the patch no-op'ing DefaultType
> are all the same person)

This person hasn't killed off all the MSIE users so the other action was premature.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: What replaces DefaultType in 2.4? [ In reply to ]
On Wed, Jan 21, 2015 at 9:46 AM, Curry, Alan <pacurry@tsc.k12.in.us> wrote:
> Header setifempty Content-Type application/octet-stream


Unfortunately C-T is special. It is tracked internally as a
non-header until the very last second and then added as a
content-header as the headers are being written to the client -- so
lots of the usual tricks will be running too early to see it before
it's set.

--
Eric Covener
covener@gmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org