WebPagetest Forums

I'm making API calls to the public instance. However, I seem to be having difficulty with the Dulles_MotoG locations.

I'm doing an HTTP get on:

u'http://www.webpagetest.org/runtest.php?url=utl-to-test&f=JSON&private=1&fvonly=0&location=Dulles_MotoG:Motorola G - Chrome&k=mk-key

then downloading the summary/details files by name.

Making calls with a location of:
Dulles_MotoG:Motorola G - Chrome
Dulles_MotoG:Motorola G - Chrome Beta
Dulles_MotoG:Motorola G - Chrome Dev

allows me to successfully download summary/details files, but the headers of the files seem to be different to those downloaded from other location/browser combinations.

For example: I expect the first five columns in the summary file to be:
Date,Time,Event Name,URL,Load Time (ms)
(as documented here: https://sites.google.com/a/webpagetest.o...st-results)

but for these MotoG browsers I'm seeing:
loadTime,docTime,fullyLoaded,bytesOut,bytesOutDoc


Making calls with a location of
Dulles_MotoG:Motorola G - UC Mini Dulles or
Dulles_MotoG:Motorola G - Opera Mini

also results in an empty details file.

I'm new to this, so apologies if I'm missing something obvious. Is there a different results format for some browsers (if so, which?) and is there something I can do to get a valid details file?

Make sure you urlencode all of your parameters. Spaces aren't allowed in URL's. Replace them with + for a simple case but it's safest to just urlencode each one (the url to be tested in particular is one people trip over all the time).

(07-28-2016 09:05 AM)pmeenan Wrote: [ -> ]Make sure you urlencode all of your parameters. Spaces aren't allowed in URL's. Replace them with + for a simple case but it's safest to just urlencode each one (the url to be tested in particular is one people trip over all the time).

Aargh. I would have said "but I tried that and it made no difference" but today it works perfectly, so I obviously just messed up somehow.

Thanks very much for the swift response!

Actually, it is not working perfectly after all.

This URL:


fails. This URL:


(the same, but with the = between "location" and the location string also encoded) appears to succeed. However, I suspect that might be because it renders the whole location parameter invalid, and it falls back to the default.

I see the same behaviour if I encode the spaces as %20 instead of +.

By 'fails' I mean that the request is placed successfully, the test runs, but the downloaded details file is empty.

I'm not sure that this is an encoding issue. For example, a location string of "ec2-us-east-1:IE 11.3GFast" (which also contains a space) works fine regardless of whether the space is encoded as + or %20.

It's just the Dulles_MotoG location strings that fail as originally described.

Have you tried just using the URLs in a browser first? I think one issue may be the upper-case JSON (pretty sure it is supposed to be lower-case) but this worked fine for me:

Hi, thanks for the reply.

Yes, I've tried the URLs in a browser; the behaviour is exactly the same. Copy-pasting your URL above also displayed the same behaviour.

Using your URL, the JSON returned says:

"summaryCSV":"http://www.webpagetest.org/result/160801_XK_bf53ba6145619e56eaa6649e685ad527/page_data.csv"
"detailCSV":"http://www.webpagetest.org/result/160801_XK_bf53ba6145619e56eaa6649e685ad527/requests.csv"

Downloading those files returns a summary file with different headers from normal, and a blank details file.

Those files won't return anything useful for UC mini. There is no waterfall data so the requests will be empty and the summary data (if it returns anything) will only include the visual metrics because that is all that is captured.

OK, so the unexpected results are, in fact, expected (just not by me )

Is there anywhere I can read about which results are available from which locations, so I expect the right things?

Many thanks for your help.