runtest.php Returning Blank Content


I am having a weird issue with our internal WebPageTest instance.

When I go to submit a test runtest.php returns a 200 and no content to the client. The job actually does get submitted - the remote Windows host sees the job and runs what was requested (and then returns the results to the server like it should), but all the client gets back from runtest.php is a 200 and no content. When I run a test from the public servers I see runtest.php return a 302 with a redirect to the test results URL.

I’m running out of ideas here for how to troubleshoot this. I’ve had WebPageTest up and running before, but I’m trying to move it to a new host.

The host is a RHEL5.5 server with PHP 5.3.8 and Apache 2.2.21.

Is there a way to increase the logging level from none to some? Or, any ideas as to where to go from here?

  • Matt

There isn’t any logging inside of the runtest.php code (though there is a basic logging infrastructure in place, I just haven’t had to instrument that part of the code before).

Are you submitting directly through the UI or are you calling it from a command line? Just doing a sanity check to make sure you aren’t passing a format specifier (&f=xml or &f=json or something like that). You still shouldn’t get an empty document but that would explain a 200 response. If mod_rewrite isn’t working it might also explain it if the redirect sends them to a page that then doesn’t work.

Anything interesting in the access logs?

Yeah, I’m running it via the UI. (I should have mentioned this is a new 2.4 install - I was using 2.3 before.)

mod_rewrite is working - if I hit one of the rewritten URLS (/about, /results, etc) it works great.

Here’s a sample from access.log:

[font=Courier]2011-10-31 09:20:56 - thebigs POST /runtest.php HTTP/1.1 200 - 0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/534.51.22 (KHTML, like Gecko) Version/5.1.1 Safari/534.51.22 o=8536dc7c4cd9de2b067585f8efa535eab916a4df; expires=Tue, 30-Oct-2012 14:20:56 GMT; path=/ cfg=NIC_IE.DSL; d=1500; l=50; p=0; runs=1; testOptions=0; u=384; o=8536dc7c4cd9de2b067585f8efa535eab916a4df; tzo=-300; as=1 http://thebigs:8080/ -[/font]

You can see it’s running a 200 and I’m pretty sure it should be returning a 302.

I can share a packet trace with you of exactly what I’m seeing if it helps.

  • Matt

I figured this out. It’s actually a bug in WebPageTest.

I was building a fresh install of Apache and PHP 5.3 for WebPageTest, including only the modules that WPT needs to run. Following the directions listed here: I only turned on gd and curl.

I traced out the error to gz_file_put_contents() inside of In here there is a call to gzopen(), which is part of the zlib module. The zlib module is not included in PHP by default, and since it wasn’t listed as a dependency I didn’t built it.

It looks like this has come up before – someone added “nogzip” to settings.ini, but it’s commented out by default. (I could have uncommented this and set it to 0 to get around this.) The line where it was actually halting is:

[font=Courier]$zip = gzopen(“$filename.gz”, ‘wb9’);[/font]

It’s halting because gzopen is only there if the zlib module is built and enabled. (Why it wasn’t returning an error to the console I’m not sure and didn’t take the time to dig into it.)

The “bug” here is that zlib is a dependency and isn’t listed in the docs. :slight_smile:

I have attached a patch to this post that fixes this issue – in addition to making sure nogzip is not enabled in settings.ini it also makes sure that the zlib module is enabled before trying to use it.

The “easy” thing to do is just list zlib as a dependancy.

What I chose to do is just rebuild PHP to include zlib since there are other benefits as well, but figured I’d reply back here in case anyone else runs into this issue.

Thanks for the awesome tool!

  • Matt

Very cool, thanks for tracking that down - I was about to add a bunch of logging so you saved me a bunch of time :slight_smile:

I’ll update the docs and merge your patch in for the next release.

I totally agree

I totally agree