New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use mimetype rather than doctype for HTML decisions #439

Closed
GoogleCodeExporter opened this Issue Apr 6, 2015 · 4 comments

Comments

Projects
None yet
1 participant
@GoogleCodeExporter

GoogleCodeExporter commented Apr 6, 2015

In various places in the code we make XHTML vs HTML decisions based on doctype. 
 We should instead be using mimetype.

Example:
http://code.google.com/p/modpagespeed/source/browse/trunk/src/net/instaweb/rewri
ter/javascript_filter.cc#240

Original issue reported on code.google.com by jmara...@google.com on 20 May 2012 at 1:36

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

Original comment by jmara...@google.com on 8 Jun 2012 at 6:20

  • Changed state: Started
@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

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?

Original comment by jmara...@google.com on 8 Jun 2012 at 10:30

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

This issue was closed by revision r1657.

Original comment by jmara...@google.com on 14 Jun 2012 at 3:08

  • Changed state: Fixed
@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

Original comment by jmara...@google.com on 14 Jun 2012 at 3:11

  • Added labels: Milestone-v23, release-note
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment