On Friday 07 February 2003 09:32 am, you wrote: > Can anyone (with a bit of spare time) give his or her ideas on > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13986 ? my 0.5 cents.
My interpretation of the RFC is that there should be a mechanism for the client to interpret the stream. This argues for the "No Content-Type" option. Reading between the lines the SHOULD on the server side, and MAY on the client side, allows content to be interpreted on the client side. This is just not possible, without violating the RFC, if the server always forces the type. This doesn't take control away from sysadmins, the ones who can have tight control over the content can still specify completely the content types that their servers use. The ones that have less control over the type of data that is served can choose to use no Conteht-Type, or a specific one through the directive. So the default configuration of Apache should include, as it does, a way to identify well known types. Then hands off on the guess, unless specifically overridden by a human. from the RFC: 3.7 HTTP uses Internet Media Types [17] in the Content-Type (section 14.17) and Accept (section 14.1) header fields in order to provide open and extensible data typing and type negotiation. note the "open and extensible".... most completely achived by not
