We recently had this issue when moving a site to a live webserver, where the proxy wasn't set up yet.

When the http request in htmlpurifier_cron() fails, null gets saved into the htmlpurifier_version_current variable. This means that the current version number gets overwritten with nothing. Then when htmlpurifier_init gets called, if the user has admin rights, htmlpurifier_cron is called to try and grab the current version number on every page load, which means a delay (10s for us) on every page load.

I'll submit a patch for this when I get the chance - but it someone else wants to do it in the meantime, it's a pretty simple one (Just checking the return on drupal_http_request inside htmlpurifier_cron and maybe logging that the reqest failed should sort it).

#6 586746-htmlpurifier.patch3.49 KBJohn Morahan
Members fund testing for the Drupal project. Drupal Association Learn more


ezyang’s picture

I'm not quite sure the proposed fix works: isn't the pre-initialized state of the version variable also null?

rupertj’s picture

Good point. What I described above would fix the case when you're migrating an existing site to a new environment that's badly configured, or when an existing site can't reach the URL in the module (And this could include the hosting at the location of the current version going down...)

What we could do is save a special value on failure, and while that value's there stop the runtime check. Then we can write a message to the status report and record that we couldn't contact the remote server to grab the current version.

If that's set up like that, when the module's freshly installed, the value would be null and the check runs. Then while there's a value in there, the check runs. Should the check ever fail, the version check at runtime is disabled (as described above), but will still run when called by cron (which will hopefully insert the correct value when connectivity comes back).

Sound good?

ezyang’s picture

This seems like quite a bit of edge case. However, if you supplied a patch, I'd be happy to accept it.

ezyang’s picture

Title: Call to get current version can cause slow page loads when running on a webserver that can't contact the outside world. » Rate limit new version checks

Renamed ticket.

newz2000’s picture

Hi, for security reasons we don't allow our web services to make http requests to external sites. We use a firewall to block outgoing requests. Therefore we've bumped into this problem on all of our web servers.

The interesting thing is that the delay (about 15s for us) causes other key parts of Drupal to break. For example, while experiencing this bug we are unable to create views because the delay causes the ajax to error out.

Our temporary solution has been to add the site to /etc/hosts file. If I can come up with a patch to fix this, I will, but at the moment it is a problem.

John Morahan’s picture

Version: 6.x-2.0 » 6.x-2.3
Status: Active » Needs review
3.49 KB

patch based on rupertj's idea

ezyang’s picture

Status: Needs review » Fixed

Fixed in CVS. Thanks for the patch!

Status: Fixed » Closed (fixed)

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