httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Curry, Alan" <>
Subject RE: [users@httpd] What replaces DefaultType in 2.4?
Date Wed, 21 Jan 2015 14:46:30 GMT

Eric Covener [] wrote:

> On Tue, Jan 20, 2015 at 11:09 AM, Curry, Alan <> 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:

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:
For additional commands, e-mail:

View raw message