Prior to 0.10.19.*, mod_pagespeed would never initiate a rewrite for HTTPS
resource because CreateInputResource would return NULL based on the scheme of
the resource.
Now it will go through the entire rewriting flow until the fetch. The fetcher
will fail reasonably fast, but at a minimum it will log the failure in
error.log, which causes system load.
I think we can get back to a situation where there's a pretty fast failure
earlier in the flow, if we do something like this:
1. Add "bool UrlAsyncFetcher::SupportsHttps(), base-class returns false.
Existing fetchers will not override. Alternatively, have "bool
UrlAsyncFetcher::PrevalidateUrl(const GoogleUrl&)", base-class checks
.scheme=="http". It could also check the syntax of the domain & the req
headers or something; not sure what's best here. The idea here is that this is
a syntax check: no system-calls should be made or threads should be spawned.
2. CreateInputResource will do an origin-map / lookup in LoadFromFile map, and
determine whether we'd ever be able to fetch such a resource using
PrevalidateUrl or SupportsHttps.
Original issue reported on code.google.com by jmara...@google.com on 5 Dec 2011 at 2:12
The text was updated successfully, but these errors were encountered:
I repro'd this as follows:
* Use local Apache installation
* Disable any https -> http mapping in pagespeed.conf
* Add "ModPagespeedDomain https://*/" to pagespeed.conf [authorizes https
resource URLs]
* Create /usr/local/apache2/htdocs/mod_pagespeed_test/https.html:
<html>
<head>
<title>HTTPS test</title>
<link rel="stylesheet" type="text/css" href="https://localhost:8443/mod_pagespeed_test/invalid.css">
</head>
<body>
Try fetching a resource using https.
</body>
</html>
* Run Apache (in gdb if desired)
* wget --no-check-certificate
http://localhost:8080/mod_pagespeed_test/https.html
You get an error in /usr/local/apache2/logs/error_log when
serf_url_fetcher_async.cc FINALLY gets around to NAKing the request.
Now working on short-circuiting this. Either as above or in Domain Lawyer logic.
Domain Lawyer is really only used by Apache and this issue is really Apache
specific (AFAIK), so it's a possible place to do it, though the problem
actually lies in the fetcher being used and once the SERF fetcher is changed to
support https this would stop it from working so it's not the correct place to
do it. Investigating.
Original comment by matterb...@google.com on 5 Dec 2011 at 3:42
Original issue reported on code.google.com by
jmara...@google.com
on 5 Dec 2011 at 2:12The text was updated successfully, but these errors were encountered: