Bug 13986

To clarify, the fix we would like to see would be that by default, if Apache
doesn't know (e.g. from extension mapping) what a file's MIME type is, it not
include a Content-Type header at all in the response header.

I suppose it might be reasonable for Apache to not send a content-type header
if DefaultType is not sent.  But I doubt such a change will make it into
1.3.  You may have better luck targetting 2.0.  And supplying a patch
would also increase your chances.

Who you should really be lobying is Microsoft.  Apache is being perfectly
standards compliant here.  It is Microsoft's violation of the standard that
is causing problems.

I am lobbying Microsoft already, although as they consider their content
sniffing to be a "feature" it is hard tc convince them to change.

Moving bug report to the Apache httpd-2.0 product.

I don't think Apache sending binary content back as text/plain is correct
behaviour, though. The default, for cases when authors have not set up their
server, should in my opinion be "we don't know", not "this is a text file".

So there are actually two issues here:

1)  If DefaultType is not set, it would be nice to not send a Content-Type header
    or to send one that allows the user to select what to do with the content as
    opposed to one that forces any compliant UA to render the content inline
2)  DefaultType should not be set in the default (example?) config file.

Created attachment 3616 [details]
A suggestion

This is based on a few hours of looking at the code and zero prior knowledge of
it.  So I strongly suspect that the details are not quite up to snuff.  But the
general idea is pretty simple...  Note that the changes only kick in if there is
no DefaultType directive.  If people are OK with these changes, changing the
default httpd.conf would be pretty simple...

There are two spots (marked with XXX comments in the patch) where I was _really_
not sure what the right thing to do was.  Also, I changed the multipart code to
not send a content-type for a subpart if one is not set, but it may be a better
idea to default that to application/octet-stream instead.  I'm not sure which
RFC is most relevant there and what sorts of problems that change could cause.

On another note, how is UA support for HTTP X where X > 0.9 responses with no
content-type set?  Is this a feasible approach in general?

Created attachment 3617 [details]
I should build before posting and remember C better..

You should also comment out the DefaultType thing in
docs/conf/httpd-std.conf.in, so that this actually does happen by default, no?

Yes, of course.

See also Bug 14095, a workaround until this bug is fixed.

So.. I just saw this blurb about Apache 2.0.44 on http://httpd.apache.org/ :

  "This release begins a new effort to retain configuration and module-interface
   stability in the Apache 2.0 series.  No changes in configuration or third-party
   modules are necessary to upgrade from 2.0.42 or later, and we will make every
   effort to maintain this easy upgrade path in future 2.0 releases."

How does that affect this enhancement request (if at all)?

hmmm. sorry for jumping so late in, but:

- an explicitly called "DefaultType None" would be probably better than a
(none-)value triggered by the absence of the directive (I've just hurried over
the patch, so forgive me, if I didn't see the obvious ... ;-)

- IMHO there's already a content-type for arbitrary data:
application/octet-stream (see, for example, RFC 2046). Or do I misunderstand
something?

However, thanks for bringing up the issue: yes, 2.0 probably won't include such
a feature. 2.1/2.2 will be the next possible stage. Sorry.

Oh yes, there's been plenty of discussion of your second point. See
http://bugzilla.mozilla.org/show_bug.cgi?id=175848 ... At a minimum.
application/octet-stream is probably not appropriate for files that are really
text/plain. Since it's not exactly arbitrary (binary) data, but unknown data.

Specifically, the point is that if a Web browser is handed a stream with an
explicit MIME type, it must not sniff the content to determine the actual MIME
type, whereas if there is no explicit Content-Type, then it can.

If Apache doesn't know, then it should let the Web browser sniff, and the only
way to do this is to not sent a Content-Type header at all.

André, You're right. "DefaultType None" would indeed make sense (and could then
be the default value in the absense of that directive).

The patch could be easily modified to do this, I think -- just ignore the
DefaultType directive if the type it sets is "None"....

That said, I'm not sure I made it clear that the patch is completely untested
and that I'm not likely to be able to test it rigorously (unless there's a
publicly available regression suite for httpd?).  I just read through the patch
again and looked at http://httpd.apache.org/dev/patches.html, and I think I may
have a few tabs in there and one place where a boolean operation is at end of
line instead of start of line; I can certainly fix those.

Any advice as to how the process goes from here?  Should I send mail to
dev@httpd.apache.org ?  Or is this bug report sufficient?  Should I just be
patient and wait?

I guess what I'm really saying is, I'm willing to spend more time polishing the
proof-of-concept here if the basic idea (and basic approach of having a NULL
char* for the header value?) is deemed sound and if the core group wants to take
the patch.  If not, I'd naturally rather not waste time on it.  ;)

Please let me know.

Well, I've read now through the bugzilla thread at mozilla org.
Principially I disagree, that Apache is to blame about the wrong content-type.
If the webmaster is not able to configure the server well (at least by request),
he should take his hat and do another job elsewhere - far far away (sounds hard?
maybe.)

However, a "DefaultType None" feature would be rather simple to build in,
although I wouldn't make it default. RFC 2616 is quite clear about it.
"Content-type SHOULD be set, blah", which basically means "set it always, unless
there are _real_ good reason to omit it".

If I understand the nature of the (mozilla) bugreport, this probably wouldn't
help you, because it relies on dumb admins, that leave all default stuff in.

The next, more practical point is - it would break some modules (just grep the
source tree for ap_default_type), since these rely on a real non-NULL
content-type. Because of this, I'm very sure, it will never apply to the 2.0
branch. (API compat)

ok, and now?
Let's have a short look back to mozilla. The people decided to accept CSS files
only with the approriate MIME type (text/css), which is of course absolutely
correct. What did really happen? Some people complained in newsgroups,
mailingslists etc ("scream, why do my CSS not work?") and were teached to
configure their servers properly or alternatively harrass their ISPs to do it
for them.
My conclusion: if it's neccessary, the people _do_ configure their servers.

I'd suggest: if you still want to patch it in Apache, ask the people on the
devlist about their opinion (please ask more times, if nobody responds ;-)

(Just an idea: maybe, a simple patch of the default config would also be
sufficient (AddType directives) for your problem?)

But said all that, the main problem you're trying to solve is neither in Apache
nor in Mozilla (or whatever browser). It's in the world out there ... YMMV.

HTH.

André, the basic problem I am trying to solve is that with a properly configured
web server a user adding a file of a type the server does not know will
automatically get the file sent as text/plain.

The SHOULD is not a MUST, imo, because the server shouldn't send the type if the
type is unknown... 

Point taken about modules; I was somewhat afraid of that.  Note that my patch
fixes everything that just such a grep found in the default source tarball, but
I'm sure many other modules exist that depend on it.  :(

I think we all agree that most web server admins out there should be flogged. 
The question is how to make life as good as possible for the users without
violating standards while we flog them one at a time (and the Mozilla project
_does_ spend a lot of time evangelizing developers on MIME type issues)...

I'll ask on the dev list as you suggest.  Thank you.

As an example of the kind of pressure Mozilla developers get put under, see this
thread:

http://www.mozillazine.org/forums/viewtopic.php?t=5367

Here, a writer says the Mozilla team is "on crack" because they won't cave in
and make their browser second-guess MIME types in blatant violation of the
standards.

The world seems to be full of people who think that, misfeature for misfeature,
whatever MSIE does defines the "standard".  :(

the relevant part of RFC 2616 is 7.2.1 which says...
   Any HTTP/1.1 message containing an entity-body SHOULD include a
   Content-Type header field defining the media type of that body. If
   and only if the media type is not given by a Content-Type field, the
   recipient MAY attempt to guess the media type via inspection of its
   content and/or the name extension(s) of the URI used to identify the
   resource. If the media type remains unknown, the recipient SHOULD
   treat it as type "application/octet-stream".

You have to balance out the SHOULDs imposed on the server with the with the MAYs
imposed on the UA. Yes, the server admin should have as complete a list of
mime-types as possible. It is still possible at that point, to have a file on
the server of which the media type is legitimately unknown even with a clueful
sysadmin. Perhaps because it is so new that it's not on the list, or some user
just invented it and didn't notify the admin yet. In that case, what should the
server do? It doesn't know the right type ... so it should do whatever is the
nicest thing for the UA. That is, provide no mime-type, the /only/ condition
under which the UA is allowed to guess.

Implementation issues notwithstanding...

I think, I understand your problem. And I further agree that we should give the
user/admin the possibility to explicitely send no content-type header.

But it should not be default,

(a) because of the SHOULD rule (set DefaultType application/octet-stream and,
though it's not the right type, you're safe anyway!)
(b) backward compat.

Over the night I've thought about the implementation issues again. Perhaps we
can also use a kind of internal magic content type (this has a long tradition in
apache code ;-). This is, however, deprecated, but IMHO arguable against NULL
pointers there. And I think, it has to be decided on the dev list.

e.g.:
DefaultType None
would set the default type to httpd/x-no-content-type or somewhat. And perhaps a
protocol filter (or something near transcode stage, I'm not sure where it should
apply best, at the moment) removes that type then from the network output.

A further problem are subrequests (whatever implementation is used). Sometimes
(mostly?) they rely on getting a reliable content type.

Remember also, it's only an idea, so it may or may not implementable that way ...

If I understand the HTTP/1.1-RFC correctly, Apache MUST NOT send an Content-
Type header if it does not know what it is sending. If they would have wanted 
that, they would have used the word MUST. They used the word should to make 
clear that the webserver should make every effort to send an correct and 
appropriate Content-Type header.
Sending a header of text/plain in cases that the content-type is unknown goes 
against what the HTTP-specs say. If the server doesn't know, perhaps the client 
will (should sniff the content an/or extensions). And if it doesn't, then it 
should tread it as application/octet-stream. This decision lies with the 
client, not the server.

Yes, right from that standpoint. But Apache _does_ know what he sends, because
he was configured so. DefaultType is not a hidden feature, it's well documented.
The DefaultType _can_ be changed. If someone wants Apache to send another
Content-type for a certain resource, he has to configure the server properly.
There are a lot of possibilities (mime.types, ForceType, AddType, (DefaultType),
magic, filters, mod_rewrite ...). It's at least possible to set DefaultType
application/octet-stream, which is never wrong if he doesn't it better.

(But again, I agree, DefaultType None, may be useful sometimes).

   But Apache _does_ know what he sends, because
   he was configured so.

I have to disagree here. Apache doesn't know what it is sending, it just 
sending what someone told it. That's is not the same! I'm sure they didn't 
thought of it like that when writing the HTTP-specs.

Setting the DefaultType to octet-stream by default goes against the RFC-specs, 
this is a decision for the client, not the server. The reason for it is 
problably when the client knows some unofficial/propriety MIME-types, unknown 
to Apache. Apache would send for instance a Mimi-Type of text/plain (current) 
or octet-stream. The client is not allowed to verify this (see HTTP-specs) and 
thus have to display the content as text or saving it as a file as bytes. But 
this may not be what the author intended.

My suggestion would be that either the defaultype is removed or set to None (by 
default). But, why does the DefaultType exists anyway? It is not correct by RFC 
(in most cases), it just a practicallity.

> Apache doesn't know what it is sending, it just 
> sending what someone told it. That's is not the same!

Maybe. But that's the only way every software works. So that difference is not
very interesting for now.

> Setting the DefaultType to octet-stream by default goes against the RFC-specs,

??
 
> this is a decision for the client, not the server. The reason for it is 
> problably when the client knows some unofficial/propriety MIME-types, unknown 
> to Apache. 

Again: you can teach apache these types. That shall be wrong? Can't believe that.

> [...] The client is not allowed to verify this (see HTTP-specs) and 
> thus have to display the content as text or saving it as a file as bytes. But 
> this may not be what the author intended.

If the author intends a content type, he can advise the httpd in various ways to
send it. All of these ways are quite simple.

*sigh* we spin round again and again.

Neither the server nor the client knows what is sent. They both have to be
configured to recognize something. Let the people configure their software
properly and everything is fine. Don't blame apache for dumb admins. Blame the ISPs!

> But, why does the DefaultType exists anyway? It is not correct by RFC 
> (in most cases)

I don't believe that. But however, this is not a problem. I'm also concerned
about compat. The Apache doesn't exist only for Mozilla. What about the
thousands of browsers out there? How do they work without getting a content type?
I don't know, are there any infos available?

   Maybe. But that's the only way every software works. So that difference is
   not very interesting for now.

It is, because in this case the HTTP-RFC states the client should decde what is 
the appropriate MIMI-type


   ??

Sorry, I meant to that sending the Content-Type octet-stream (as suggested 
earlierer) in cases Apache doesn't know the MIME-type goes against the HTTP-RFC 
(which states the client should make this decision)

 
   Again: you can teach apache these types. That shall be wrong? Can't 
   believe that.

Yes you can, but if that is what you want, Apache should include these MIME-
types by default.


   If the author intends a content type, he can advise the httpd in various
   ways to send it. All of these ways are quite simple.

But the DefaultType has nothing to do with intending a content-type. Or, I 
don't think many webmasters use it this way...


  *sigh* we spin round again and again.

Perhaps this is a discussion for the Apache developers maillinglist.


  Neither the server nor the client knows what is sent. They both have to be
  configured to recognize something. Let the people configure their software
  properly and everything is fine. Don't blame apache for dumb admins. Blame
  the ISPs!

Indeed, people's software should be properly configured. But if this is the 
case, Apache should not send a Content-Type header for unknown content! 
Otherwise, people's software cannot recognize what Apache is sending! 
(remember, if Apache sends a content-type, the client MUST not question it, 
according to the HTTP-RFC)


  I don't believe that. But however, this is not a problem. I'm also concerned
  about compat. The Apache doesn't exist only for Mozilla. What about the
  thousands of browsers out there? How do they work without getting a content   
  type?

That is a concern, but is it Apache's problem? Browsers should work according 
to the HTTP-RFC (that's why they are for). If they don't, should Apache also 
disregard the HTTP-RFC?


  I don't know, are there any infos available?

To my knowledge, IE should work fine. Many other browsers look at file's 
extesions to guess the MIME-type.

I think we're talking past each other.

In an ideal world, Apache would 'know' the correct mime type for any file anyone
ever wants to hand it. This would be 100% correct, and would be sent to the
browser, and everyone would be happy.

_However_, the fact is that that isn't  the case, which is why there is any sort
of default setting at all. The current Apache behaviour is to claim that
'unknown' types are application/octet-stream. This means that if I have a .svg
file, which is then sent as application/octet-stream, the browser MUST (by
RFC2616 and friends) treat it as application/octet-stream, and offer to save it
to disk rather than viewing it. The converse of this is when the default mime
type is set as text/plain. If I then download an rpm file (assuming no entry in
a mimetype file), the browser MUST show it to the user, without prompting to
save, assuming that the browser handles text/plain files. No setting for
DefaultType can win all the time.

If Apache didn't send a mime type for those cases, then the browser could sniff
the contents (similar to mod_mime_magic), or do extention matching, or ask
/dev/random, or whatever else it feels like doing. With a mime type, mozilla
MUST NOT try to guess.

IE always does sniffing, which is broken - try to feed it an SVG file as
text/plain for debugging, and watch it complain that I can't use an XML file
with a <?stylesheet directive, rather than show me plain text. This is also
against the HTTP RFC. Hixie has a set of tests to test that sort of stuff somewhere.

FWIW, None should be the default, since I imagine that thats not part of a
config file most admins are likly to change.

I fully agree.

> The Apache doesn't exist only for Mozilla. What about the thousands of> browsers out there? How do they work without getting a content type?Most other browsers (like IE) work by violating RFC 2616. This is also why sysadmins can generally get away with being lazy about setting their MIME types. Most users will never know the difference. The problem here is Mozilla is bending over backwards to try NOT to violate RFC 2616. But unless we can get some cooperation from Apache, Mozilla too will have to violate the spec. Chimera, Mozilla's Mac OS Browser, already does. They tried the evangelism route and it was like trying to bail a sinking ship with a teaspoon. The practical reality is that unless Apache removes the default MIME type or implements some kind or null default (as I believe the RFC intended) Mozilla will have to do MIME sniffing in some situations (or forget about trying to be a usable browser).

Let's try that again (somehow my linebreaks got stripped)...

> The Apache doesn't exist only for Mozilla. What about the thousands of
> browsers out there? How do they work without getting a content type?

Most other browsers (like IE) work by violating RFC 2616. This is also why
sysadmins can generally get away with being lazy about setting their MIME types.
Most users will never know the difference. The problem here is Mozilla is
bending over backwards to try NOT to violate RFC 2616. But unless we can get
some cooperation from Apache, Mozilla too will have to violate the spec.
Chimera, Mozilla's Mac OS Browser, already does. They tried the evangelism route
and it was like trying to bail a sinking ship with a teaspoon. The practical
reality is that unless Apache removes the default MIME type or implements some
kind or null default (as I believe the RFC intended) Mozilla will have to do
MIME sniffing in some situations (or forget about trying to be a usable browser).

> What about the thousands of browsers out there? How do they work without getting
> a content type? I don't know, are there any infos available?

Well...

1)  _With_ a content type all versions of Netscape, opera up through 6 (have not
    tested 7), Konqueror of all versions I have tried, Mozilla, lynx, links, w3m
    will unconditionally honor the header.  The only browser I have found that
    does not is IE.  I have been unable to test mac-only browsers such as
    omniweb or icab.
2)  Ebay does not send a content type.  I consider this a bug in ebay, but this
    means that every browser has _some_ type detection already -- not rendering
    ebay is not an option for a browser that actually wants to be used.
3)  What's the worst thing a browser could do without a content type?  Assume a
    default type of some sort?

In any case, there is a discussion I'm trying to start on the mailing list on
the topic, and indeed a lot of this would belong better there.

There's a situation where the sysadmin is /not/ in error and this is still
required. If a user is researching a new media type, has an experimental plugin
to read that type, a new extension for the type and adds that file to a random
server on the net, it is ideal in that situation to send no content-type header
and let the 2616-compliant UA sort it out. Rare? Perhaps... but valid.

  In any case, there is a discussion I'm trying to start on the mailing list on
  the topic, and indeed a lot of this would belong better there.

What maillinglist would that be?

It's dev@httpd.apache.org; to subscribe send an empty email to dev-
subscribe@httpd.apache.org (only subscribers are allowed to post).

See http://httpd.apache.org/lists.html#http-dev for further info.

I'm already a subscriber, but I only see a discussion on PHP4 and Apache2. I 
also tried posting my own message to start a discussion, but to no avail...

In my humble opinion the solution which would make most sense (disregarding the currently valid 
RFCs) would be that a user agent is allowed to sniff anyway. Because the user agent knows best what 
the user wants - and the user is the one who has to view the rpm as plaintext. Therefor an attitude like 
"Apache suggests a MIME type, use it if you want, if not try to do it better yourself" would be the 
best.
Therefor I guess the easiest solution would be to write a new RFC which supersedes the old 
one to satisfy the mozilla guys.

dev@httpd.apache.org is the mailing list.  I am going on vacation, though, so I
have had to unsubscribe.

Psychopath -- you are wrong on all counts.  There are many cases when a
well-configured server has a _much_ better idea of the content type than we do
(think something as easy as sending an HTML file as text/plain on purpose to
allow people to view the source easily without relying on the browser UI).

What you're suggesting is that every browser just act like IE, which would be a
sad thing indeed for content authors and users both.

He does have a point. The current RFC is somewhat outdated, since it oversees 
the fact that there are hostile servers which sends wrong MIME-type's on 
purpose.

I heard several years ago that HTTP/1.2 was in the works. But along the way, it 
seem to have died (somehwere in 1996). This is part of the issue. Should Apache 
follow an (perhaps) outdated RFC which is unlikely to be updated? 

"hostile"?  Eh?

Yes, Apache should absolutely follow the RFC, as should browsers.  That's the
only way to get predictable behavior that will benefit both users and authors.

Note that if IE were following the RFC none of this would be a problem, since
authors would quickly notice their servers were sending a type they did not want
and _fix_ it.

We can't do anything about IE, but randomly violating network protocols just
because we find them inconvenient is a BAD idea if you expect any sort of
interoperability.

IE will never support the RFC this way, since you could take over anyone's 
computer if it did (to my knowledge, this is the reason why IE snifs content).

That's also what I mean with hostile. Not everyone who owns a server and runs 
Apache is a "Good Person". The RFC oversees this. You cannot trust any source 
on the internet. This is however what the RFC asks. A client MUST use the 
server-supplied MIME-type.

As I said before, Apache must comply with the RFC. I just would like to point 
out that the RFC however may not be good practice anymore...

There is no way to abuse Content-Type per the RFC in such a way as to take
control of a client. Indeed, content sniffing has historically proven to be much
more susceptible to attack than honoring the HTTP specs.

What Ian said.  Mozilla does comply with the RFC and we have made sure that we
cover over the execution vulnerabilities in Windows in other ways than content
sniffing.

Imo the RFC in question is very much good practice.

Folks, this is not a discussion group.  It is a bug database.  You are actually
hurting your chances of getting anything done on this bug by making it a chore
to actually read through it.

Proper places for discussion (as already mentioned): dev@httpd.apache.org or
users@httpd.apache.org.

In general, it is absolutely the responsbility of the server to send a proper
content type, and the client should not be ignoring it.  The very specific
point of this bug report is to deal with a special case where the server
administrator has neglected to properly configure the mime type.  This is a
configuration problem, not a server bug.  But it may be appropriate for apache
to deal with this by ommitting the content-type header and thereby
pass the decision off to the client.

> The very specific point of this bug report is to deal with a special
> case where the server administrator has neglected to properly 
> configure the mime type.

As I said in my comment of 2003-02-05 18:39, it's easy to come up with a
situation where the server administrator is fully up-to-date on their duties,
but apache still does the wrong thing. The users may be experimenting with new
mime-types and UAs or plug-ins, and not alert the sysadmin. In that case, a null
content-type is the only RFC-compliant choice to allow the custom UA to sniff
and do the right thing.

Isn't that what .htaccess files are for?  (Setting up new MIME types the sever
administrator hasn't configured, I mean.)

No.

Note that this problem affects windows users as well with the WMV and ASF
extensions that it seems are often not configured correctly either.

Darn it, sure. .htaccess files are exactly for such purposes. Please don't
distribute misleading information.

Thanks.

This bug is specifically about cases where the user _isn't_ setting the file
types, and thus Apache relies on the default. In those cases, it would be better
for Apache not to send back a default type.

I'm sure we all agree that ideally users would set the type on all files.

Note that Opera Software would also really like to see this fixed. Mozilla are
not the only browser maker in favour of this fix. :-)

"Darn it, sure. .htaccess files are exactly for such purposes."

No. Read the summary. You are arguing the opposite direction. It doesn't matter
how hard you push for people to fix their mime-types and .htaccess,
statistically it is impossible for everyone to keep up to date. It is also
provably true that some people can add a file to a server but cannot edit .htaccess.

Your answer to:

| Isn't that what .htaccess files are for?  (Setting up new MIME types the sever
| administrator hasn't configured, I mean.)

was:

| No.

That is wrong. period. I don't argue against anything. I'm just rejecting
misleading information.

And hey, if the administrator decides to configure a default mime type without
granting you .htaccess rights, you're at the same point as before. But I bet,
nevertheless, once someone finds some time, he will code it into the httpd.
There's no need to restart the discussion again. *sigh*

*** Bug 14095 has been marked as a duplicate of this bug. ***

Dirk-Willem van Gulik made the suggestion that perhaps it would make more sense
to serve up and error page if the content type of the data cannot be determined
(and improve the existing content type determination methods to detect a wider
range of data).  That would make sure that server maintainers would not just
sort of assume things will work out...

Closing due to inactivity, length of time and absence of agreement. If more information
appears later, please re-open the bug.

For what it's worth, browser makers have effectively given up on getting
reliable MIME types from servers due to this bug and fallen back on
type-sniffing on the client in various cases...

I'm not sure why we would mark this as invalid. It is something that many people
would find useful, and I don't actually see any argument against implementing
it. (Although there are plenty of arguments about who is to blame for the whole
type-sniffing fiasco.) The only thing that is lacking is a developer with the
skills and time who thinks it is important enough to get it into the tree.

At worst, if you want to get rid of bugs like this, you should mark them "Later".

WTF? How did this get buried in the enhancement pile?

I answered this question about three years ago when the TAG was
drafting

   http://www.w3.org/2001/tag/doc/mime-respect

and the answer is that the server default must be removed.
There is no other way to make sense of the HTTP requirements
on both servers and UAs.

That means:
  a) remove DefaultType from the standard httpd.conf.in file
  b) add "DefaultType none" option for resetting config
  c) remove (or set to none) DEFAULT_CONTENT_TYPE
  d) make sure that the server correctly handles empty content-type

....Roy

*** Bug 14095 has been marked as a duplicate of this bug. ***

*** Bug 22920 has been marked as a duplicate of this bug. ***

*** Bug 16139 has been marked as a duplicate of this bug. ***

Fixed in trunk, but need to document "DefaultType none" option before backporting.

mod_cache may need a separate fix for this (to be investigated).

Fixed in r589616

I didnt't mean to close, but I've pushed "Mark bug as CLOSED" carelessly.
If bad, please reopen.

Since this bug wasn't intended to be closed, I am reopening it.

Restoring RESOLVED/FixedInTrunk status.

While I don't have any real expectation of action coming from a comment on a resolved bug, I still want to mention that the fix for this bug did not fix this bug: it made it _possible_ to "remove default MIME-type" while ignoring the part of comment 55 about "a) remove DefaultType from the standard httpd.conf.in file," which still combines a text/plain default with simply awful advice about using text/plain "If your server contains mostly ... HTML documents."

Agreed.

It appears that this should be reopened until the default httpd.conf is fixed.

Reopening based on comments.

There's no way we can change a default like this in a stable release: it would break far too many existing installs.

Revised defaults are an option for 2.4, but should be discussed on the dev list, not here.

Why did you close this bug, when you said "Revised defaults are an option for 2.4". It makes more sense to change the version on the bug and keep it open. Also, I don't get why this can't be discussed here, it's a perfect place to discuss the bug and the solutions, and means that I don't have to subscribe to a presumably high-volume mailing list for a single issue.

Having a "none" type is a step in the right direction, but the whole solution requires that "none" be the default, for the reasons established in previous comments. Should we open a new bug??

(In reply to comment #68)

> It makes more sense to change the version on the bug and keep it open.

This suggestion makes sense to me. I see no objections here and no discussion on the developer mailing list about the issue, so I'll reopen as a bug in the latest development version.

Fixed in trunk with rev 739382.

Disabled DefaultType directive and removed ap_default_type()
from core.  We now exclude Content-Type from responses for which
a media type has not been configured via mime.types, AddType,
ForceType, or some other mechanism.