I moved this bit to the top because I think it makes everything else irrelevant:
> Note however that old browsers who do not understand the type > "application/xhtml+xml", are *really* old. > > Note also that no matter what the server sends as Content-Type header, > if the browser is IE, it will ignore it anyway and make its own guess. No. If these statements were true, I would not have started this conversation. Every version of IE, when provided with any file, with "Content-Type: application/xhtml+xml", will make no attempt to display the page, and will ask the user if they would like to save it to a file. If you provide XHTML 1.0 to a recent version of IE with "Content-Type: text/html", it will render the page. (http://www.microsoft.com/ is valid XHTML 1.0 Transitional.) I apologize for not starting this conversation with this practical example. On 07/18, Andr? Warnier wrote: > Yes, because it would be very confusing otherwise. I disagree. > But it is not what I think that counts; what counts is the HTTP RFC. 5. Content-Type Header Field The purpose of the Content-Type field is to describe the data contained in the body fully enough that the receiving user agent can pick an appropriate agent or mechanism to present the data to the user, or otherwise deal with the data in an appropriate manner. - RFC2045 - Multipurpose Internet Mail Extensions (MIME) Part One To "...describe the data..." contained in the an xhtml file "...fully enough that..." IE "...can pick an appropriate mechanism to present the data to the user, or otherwise deal with the data in an appropriate manner", the Content-Type header must be "text/html". >> Did you read the part about why XHTML should be served to some clients as >> text/html, and others as application/xhtml+xml? > Wherever that is, I disagree with it. Content should be served with a I apologize for this as well, I thought I provided the url at the beginning of my first email: http://www.w3.org/TR/xhtml-media-types/#media-types - XHTML Media Types - Second Edition: Serving the Most Appropriate Content to Multiple User Agents from a Single Document Source Disagreeing with the W3C, author of all HTML standards which the Apache HTTPD was primarily designed to provide, on specifically what Content-Types this sort of software should use for documents it has written the standards for... seems... not useful. >> But XHTML 1.0 was created to be compatible >> with existing browsers that didn't understand XML, so they should be served >> the same file, with the different Content-Type of text/html. > That may be where we disagree. They could be sent the same content, but > not necessarily the same file. What? You feel a reason to duplicate the content why? > No, and that is where you are confused. You are confusing resource and file. > Quote from http://httpd.apache.org/docs/2.2/content-negotiation.html: I know the difference between a resource and a file. It's a pretty neat distinction. I first used it with a type-map file to serve svg to capable browsers, and a png converted from the svg to others. > A resource is a conceptual entity identified by a URI (RFC 2396). An > HTTP server like Apache provides access to representations of the > resource(s) within its namespace, with each representation in the form > of a sequence of bytes with *a defined media type*, character set, application/xhtml+xml is defined. Right here: http://www.rfc-editor.org/rfc/rfc3236.txt >From a list provided by IANA, as specified by the MIME RFCs even: http://www.iana.org/assignments/media-types/ >>>> Except I can't figure out how to provide multiple Content-Types for a >>>> single file. >>> Logical, because you can't. One document/file has only one MIME >>> type, not several. >> Why not? > That, you should ask the people who have created all these Internet > RFC's. I am sure that they have thought long and hard about it. I addressed this above by quoting RFC2045. > The server cannot answer : here is a Bourgogne or Bordeaux; quality = > 0.9. That just does not make sense, even if the Bordeaux is a Chateau > Cheval Blanc 1er Grand Cru Class? St Emilion. I have never suggested or expressed interested in using a Content-Type header with multiple types. That would obviously be useless. > But Apache should not send 2 MIME types in a Content-type header, > because that is illegal according to the HTTP specification, and Apache, > being a HTTP server, has to respect the HTTP specification. Agreed. > It /may/ work with a single file, and another symbolic link to it, but > of that I am not sure. I am surprised to find that it does not work with hard links. Even with "FileETag None". > (Personally, I think that you /should/ have 2 files, because their > content should not be identical. If they are proper html and xhtml, > then at least their DOCTYPE and <meta http-equiv="content-type"> tags > should be different) Perhaps it would be useful to say that xhtml is html, which makes it valid to call it text/html. It just also confirms to xml. Not very relevant though. There is no practical reason to have two different files in two different formats. > Note however that old browsers who do not understand the type > "application/xhtml+xml", may also not send an "Accept" header. Indeed. This was the reason the W3C recommended sending text/html to browsers which do not list it or application/xhtml+xml in an Accept header. I am far less concerned with this. > Note also that if you do not like how Apache does it, you can write your > own add-on modules to do it any way you like. > That's what filters are for. > You could probably even achieve what you want more precisely by using > the mod_SetEnvIf, mod_headers and/or mod_rewrite. These sort of possibilities have occurred to me. Thank you for pointing me in more specific directions. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org " from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
