Advagg reports a number of failures when it can't access itself via http. For example, an http server for "example.com" might for *many* reasons not be able to access http://example.com: The most common are that the network infrastructure of the server has a load balancer or something in front of it, which cannot be accessed from inside the network using the external IP. But there are many reasons this can happen.

However advagg naively reports quite a number of problems when the site can't access itself:

* Several 404 fails (which can in fact be turned off with $conf['advagg_skip_404_check'] = FALSE;) These could be a lot smarter if they realized that an http response of 0 was a signal.
* "Adv CSS/JS Agg - If-Modified-Since"

The If-Modified-Since header is being ignored by your web server.
The web servers configuration will need to be adjusted. The server should have responded with a 304, instead a 0 was returned.
* Possibly "Adv CSS/JS Agg - gzip"	Gzip is failing for css files. The web servers configuration will need to be adjusted. In most cases make sure that the webroots .htaccess file still contains this section "Rules to correctly serve gzip compressed CSS and JS files".

(Note that the code could be much smarter, understanding that a 0 was complete failure)

Is there a workaround for this problem? Since this excellent module is deployed in many production environments I'd expect to see a lot of complaints about the noise generated on admin/reports/status, but I don't see it on a casual review of the issues.

CommentFileSizeAuthor
#6 advagg-2213363-6-loopback-fix.patch6.92 KBmikeytown2
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mikeytown2’s picture

Version: 7.x-2.1 » 7.x-2.x-dev

Thanks for reporting about this; it's the first time I've encountered a report like this for AdvAgg. Do you have any suggestions on ways to fix this other than ignoring issues if the http status returns 0? The best idea I've come up with is to use some sort of proxy.

Does the status report from https://drupal.org/project/httprl/ have the same issue as AdvAgg?

rfay’s picture

Thanks for the quick reply.

It sure seems like the reaction to an http 0 would need to be different, anyway.

Sorry, although httprl is installed on this site, it's not enabled, and I'm not familiar with the module, sadly.

BTW, a simple testing technique for this genre of problems is to just break /etc/hosts on the webserver; In /etc/hosts temporarily configure a bad hostname matching the site. It's not quite as good as what's actually happening in this case (a reset/0) but it demonstrates the problem with a timeout.

mikeytown2’s picture

httprl has a threading lib that will issue requests to it's self in order to run multiple processes in parallel. It's mainly a library module so it shouldn't change much if you enable it; advagg will try to use it, but it shouldn't have a negative impact if it's not working. httprl has more complex logic for figuring out if requests to self will work. If httprl works but advagg does not then I'll have to put the more complex logic in advagg. If httprl & advagg do not work then I'll special case 0.

rfay’s picture

BTW, I am working around this by templating the /etc/hosts file with an extra entry setting the canonical name to 127.0.0.1 (localhost), short-circuiting the network architecture problem. It solves all but the gzip complaint, which I'm working on now.

mikeytown2’s picture

So it sounds like using 127.0.0.1 with the host header would be a good alt if the first try fails (similar to httprl). I'll work on a patch next week. Thanks for the hosts file tip; I'll use it when working on the patch :)

mikeytown2’s picture

Status: Active » Fixed
FileSize
6.92 KB

This patch has been committed.

It will try an alt host if the first request didn't return a positive response code.

rfay’s picture

Thanks so much for your responsiveness and for maintaining this!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.