Thoughts on this:  the challenge here is that in Apache we are not guaranteed 
to have the final word on the mimetype when mod_pagespeed runs.  

See also Issue 422.   Both these issues are most easily resolved if 
mod_pagepseed can run late; after any filter that may modify content-type, 
notably mod_headers.


The issue right now is that currently we are making a decision based on the 
DOCTYPE, which is not really accurate, however, at least we know exactly what 
the DOCTYPE is in mod_pagespeed, since most other filters don't modify content.

So this bug addresses only when the DOCTYPE is wrong.  However, if we fix it, 
then we may make the situation worse because we might make xhtml-or-not 
decisions that might be changed later, downstream of our filter.

One thought, however, is to register another output handler (actually we 
already have one: instaweb_fix_headers_filter) which could at least *detect* a 
problem by seeing whether the content-type it sees is the same as the 
content-type we saw in instaweb_out_filter.

What I haven't figured out is what we should do if we detect a problem.  Use 
the property-cache to remember the eventual content type for an HTML file, 
overriding the value we see in request->content_type?

This issue was closed by revision r1657.