httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 13986] - remove default MIME-type
Date Tue, 04 Feb 2003 12:47:15 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13986>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13986

remove default MIME-type





------- Additional Comments From nd@perlig.de  2003-02-04 12:47 -------
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 ...

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


Mime
View raw message