|Summary:||remove default MIME-type|
|Component:||Core||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
|Severity:||normal||CC:||bbaetz, bzbarsky, coad, dark1, davi, gavin.sharp, hsivonen, ian, info, julian.reschke, jvb, jwalden+apache, mail, moz, philringnalda, pixelcort, sbwoodside, xhva.net|
|Bug Depends on:|
I should build before posting and remember C better..
Description fantasai 2002-10-26 05:53:09 UTC
Because of the text/plain default, Mozilla's been having a lot of problems dealing with content from Apache servers in a standards-compliant way. It seems that a large number of server admins are not setting the proper extension -> MIME-type mappings, and all sorts of content gets sent as text/plain.* By the HTTP spec, Mozilla is forbidden any guessing if a content-type header is sent, and so it *must* treat these files as plaintext, which is inappropriate. Basically, if the content-type is really unknown, it should not be set so that the recipient may perform detection. http://ftp.ics.uci.edu/pub/ietf/http/rfc1945.html#BodyType http://www.servlets.com/rfcs/rfc2616-sec7.html#sec7.2.1 * This is probably because other browsers, including MSIE, do not adhere to this requirement, so server admins don't (and in some cases refuse to) set the appropriate mappings to override text/plain.
Comment 1 Ian 'Hixie' Hickson 2002-10-26 06:20:44 UTC
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.
Comment 2 Joshua Slive 2002-10-26 17:48:12 UTC
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.
Comment 3 Ian 'Hixie' Hickson 2002-10-26 20:58:51 UTC
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".
Comment 4 Boris Zbarsky 2002-10-26 21:16:32 UTC
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.
Comment 6 Boris Zbarsky 2002-10-26 23:13:11 UTC
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?
Comment 7 Boris Zbarsky 2002-10-26 23:28:35 UTC
Created attachment 3617 [details] I should build before posting and remember C better..
Comment 8 Bradley Baetz 2002-10-27 12:53:58 UTC
You should also comment out the DefaultType thing in docs/conf/httpd-std.conf.in, so that this actually does happen by default, no?
Comment 9 Boris Zbarsky 2002-10-27 17:06:42 UTC
Yes, of course.
Comment 10 Simon Woodside 2002-10-30 21:41:10 UTC
See also Bug 14095, a workaround until this bug is fixed.
Comment 11 Boris Zbarsky 2003-02-02 22:57:09 UTC
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)?
Comment 12 André Malo 2003-02-03 00:16:44 UTC
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.
Comment 13 Simon Woodside 2003-02-03 00:23:19 UTC
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.
Comment 14 Ian 'Hixie' Hickson 2003-02-03 02:13:50 UTC
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.
Comment 15 Boris Zbarsky 2003-02-03 03:58:07 UTC
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 email@example.com ? 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.
Comment 16 André Malo 2003-02-03 22:02:58 UTC
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.
Comment 17 Boris Zbarsky 2003-02-03 22:18:25 UTC
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.
Comment 18 Daniel R. Tobias 2003-02-04 00:28:02 UTC
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". :(
Comment 19 Simon Woodside 2003-02-04 01:03:56 UTC
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...
Comment 20 André Malo 2003-02-04 12:47:14 UTC
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 ...
Comment 21 Sander Holthaus 2003-02-04 15:49:07 UTC
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.
Comment 22 André Malo 2003-02-05 10:52:08 UTC
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).
Comment 23 Sander Holthaus 2003-02-05 11:25:21 UTC
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.
Comment 24 André Malo 2003-02-05 12:00:40 UTC
> 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?
Comment 25 Sander Holthaus 2003-02-05 12:44:58 UTC
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.
Comment 26 Bradley Baetz 2003-02-05 13:04:55 UTC
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.
Comment 27 Sander Holthaus 2003-02-05 13:35:24 UTC
I fully agree.
Comment 28 kaldari 2003-02-05 15:57:00 UTC
> 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).
Comment 29 kaldari 2003-02-05 16:04:25 UTC
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).
Comment 30 Boris Zbarsky 2003-02-05 17:06:36 UTC
> 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.
Comment 31 Simon Woodside 2003-02-05 18:39:00 UTC
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.
Comment 32 Sander Holthaus 2003-02-07 12:23:02 UTC
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?
Comment 33 Erik Abele 2003-02-07 12:31:20 UTC
It's firstname.lastname@example.org; to subscribe send an empty email to dev- email@example.com (only subscribers are allowed to post). See http://httpd.apache.org/lists.html#http-dev for further info.
Comment 34 Sander Holthaus 2003-02-07 12:34:34 UTC
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...
Comment 35 Psychopath 2003-02-07 14:38:55 UTC
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.
Comment 36 Boris Zbarsky 2003-02-07 14:43:58 UTC
firstname.lastname@example.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.
Comment 37 Sander Holthaus 2003-02-07 14:58:16 UTC
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?
Comment 38 Boris Zbarsky 2003-02-07 15:06:19 UTC
"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.
Comment 39 Sander Holthaus 2003-02-07 15:18:51 UTC
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...
Comment 40 Ian 'Hixie' Hickson 2003-02-07 15:26:30 UTC
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.
Comment 41 Boris Zbarsky 2003-02-07 15:32:26 UTC
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.
Comment 42 Joshua Slive 2003-02-07 16:19:24 UTC
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): email@example.com or firstname.lastname@example.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.
Comment 43 Simon Woodside 2003-02-07 17:12:00 UTC
> 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.
Comment 44 Daniel R. Tobias 2003-02-08 02:05:51 UTC
Isn't that what .htaccess files are for? (Setting up new MIME types the sever administrator hasn't configured, I mean.)
Comment 45 Simon Woodside 2003-10-22 07:29:31 UTC
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.
Comment 46 André Malo 2003-10-22 07:40:15 UTC
Darn it, sure. .htaccess files are exactly for such purposes. Please don't distribute misleading information. Thanks.
Comment 47 Ian 'Hixie' Hickson 2003-10-22 09:19:35 UTC
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. :-)
Comment 48 Simon Woodside 2003-10-22 18:30:43 UTC
"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.
Comment 49 André Malo 2003-10-22 18:51:54 UTC
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*
Comment 50 Erik Abele 2004-01-05 21:57:25 UTC
*** Bug 14095 has been marked as a duplicate of this bug. ***
Comment 51 Boris Zbarsky 2004-02-14 00:35:47 UTC
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...
Comment 52 Davi Arnaut 2007-06-08 11:45:40 UTC
Closing due to inactivity, length of time and absence of agreement. If more information appears later, please re-open the bug.
Comment 53 Boris Zbarsky 2007-06-08 12:08:50 UTC
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...
Comment 54 Joshua Slive 2007-06-11 11:10:26 UTC
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".
Comment 55 Roy T. Fielding 2007-08-25 12:03:56 UTC
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
Comment 56 Roy T. Fielding 2007-08-27 10:31:10 UTC
*** Bug 14095 has been marked as a duplicate of this bug. ***
Comment 57 Nick Kew 2007-09-15 07:03:26 UTC
*** Bug 22920 has been marked as a duplicate of this bug. ***
Comment 58 Nick Kew 2007-09-27 05:44:26 UTC
*** Bug 16139 has been marked as a duplicate of this bug. ***
Comment 59 Nick Kew 2007-09-27 05:47:16 UTC
Fixed in trunk, but need to document "DefaultType none" option before backporting. mod_cache may need a separate fix for this (to be investigated).
Comment 61 Takashi Sato 2008-01-19 09:10:09 UTC
I didnt't mean to close, but I've pushed "Mark bug as CLOSED" carelessly. If bad, please reopen.
Comment 62 Julian Mehnle 2008-01-19 14:10:33 UTC
Since this bug wasn't intended to be closed, I am reopening it.
Comment 63 Julian Mehnle 2008-01-19 14:12:11 UTC
Restoring RESOLVED/FixedInTrunk status.
Comment 64 Phil Ringnalda 2008-07-03 00:07:23 UTC
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."
Comment 65 Julian Reschke 2008-07-03 00:44:13 UTC
Agreed. It appears that this should be reopened until the default httpd.conf is fixed.
Comment 66 Steve Chapel 2008-12-16 07:29:18 UTC
Reopening based on comments.
Comment 67 Nick Kew 2008-12-16 15:28:15 UTC
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.
Comment 68 Simon Woodside 2008-12-17 18:19:40 UTC
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??
Comment 69 Steve Chapel 2008-12-26 12:12:53 UTC
(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.
Comment 70 Roy T. Fielding 2009-01-30 11:26:55 UTC
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.