Rate limit new version checks [#586746]

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).

Comment	File	Size	Author
#6	586746-htmlpurifier.patch	3.49 KB	John Morahan
#6

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

ezyang CreditAttribution: ezyang commented 24 September 2009 at 16:23

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

Comment #2

rupertj CreditAttribution: rupertj commented 25 September 2009 at 08:35

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?

Comment #3

ezyang CreditAttribution: ezyang commented 28 September 2009 at 17:29

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

Comment #4

ezyang CreditAttribution: ezyang commented 13 December 2009 at 01:12

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.

Comment #5

newz2000 CreditAttribution: newz2000 commented 7 July 2010 at 17:21

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.