httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [users@httpd] How do I follow the XHTML Content-Type recommendations?
Date Sat, 18 Jul 2009 04:14:51 GMT
I moved this bit to the top because I think it makes everything else

> 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.


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.  ( is valid
XHTML 1.0 Transitional.)

I apologize for not starting this conversation with this practical

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: 
- 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

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:

>From a list provided by IANA, as specified by the MIME RFCs even:

>>>> 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.


> 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:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message