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 [EMAIL PROTECTED] 2003-02-04 01:03 ------- 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... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
