You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 21, 2023. It is now read-only.
In r1231 (ref issue 357), ModPagespeedLoadFromFile started stripping query
params from the resource name before loading it. However, it seems that the
query string params are still affecting the output in that they aren't stripped
before determining the content type of certain resources. I'm seeing a lot of
these in my log:
[Thu Mar 29 13:45:03 2012] [error] [mod_pagespeed 0.10.21.2-1381 @6876] Loaded
resource with no Content-Type
http://mysite.com/wp-includes/js/thickbox/thickbox.css?ver=20111117
It causes problems because that rewritten stylesheet is then served with a
text/plain Content-Type header, effectively rendering it useless the first time
it's served. Subsequent requests to that same resource load the mod_pagespeed-
processed and cached resource, which then has the correct content type.
Removing the ModPagespeedLoadFromFile directive and making mod_pagespeed fetch
the file over HTTP resolves that issue.
The fix is to strip query params from the file name before determining the
content type that's served for the not-yet-processed resource in the initial
hit.
Original issue reported on code.google.com by amat...@gmail.com on 29 Mar 2012 at 8:54
The text was updated successfully, but these errors were encountered:
To clarify, I believe this is only a problem when the rewrite deadline is
exceeded. That can happen, for example, when a CSS file contains a ton of
images in it and mod_pagespeed has to process / inline them all. If the CSS is
processed within that deadline, it seems the correct content type is returned
in spite of the logged error.
Original comment by amat...@gmail.com on 30 Mar 2012 at 5:27
Aha, I can see how this is a problem.
When loading from file, we can only guess the file type based upon the
extension and we are not correctly ignoring the query for this situation.
Looks easy to fix. I'm working on it now.
Thanks for the report.
Original comment by sligocki@google.com on 30 Mar 2012 at 5:35
Original issue reported on code.google.com by
amat...@gmail.com
on 29 Mar 2012 at 8:54The text was updated successfully, but these errors were encountered: