WebPagetest Forums
blocking requests doesn't seem to work - Printable Version

+- WebPagetest Forums (https://www.webpagetest.org/forums)
+-- Forum: WebPagetest (/forumdisplay.php?fid=7)
+--- Forum: Bugs/Issues (/forumdisplay.php?fid=10)
+--- Thread: blocking requests doesn't seem to work (/showthread.php?tid=12310)



blocking requests doesn't seem to work - nilskuhn - 06-06-2013 01:45 AM

Hi,

I am trying to block a single request (a gif) for a test with chrome. Don't get it to work:
http://www.webpagetest.org/result/130605_XV_YD9/

Example-result was tested with the following script:
Code:
ignoreErrors    1
logData    0
setCookie    http://otto.de
setCookie    http://beta.otto.de
setCookie    http://a1.beta.otto.de
navigate    https://beta.otto.de/damenmode/kategorien/hosen/
logData    1
block ottorum.gif
execAndWait     document.querySelector('#san_searchResult section div:first-child a').click();

I've also tried to add the ottorum.gif in the web-UI, no success :-(
Or do I have to use a regex instead (something like /.*ottorum\.gif.*/ )?

Can anybody give me a clue? Or has a working blocking-example for chrome?
Regards, Nils

Hint: If someone wishes to reproduce the problem please contact me for getting the cookie.


RE: blocking requests doesn't seem to work - pmeenan - 06-06-2013 07:20 AM

You shouldn't have to do a regex. It does a substring (case-sensitive) match. I think what is happening is that the request is successfully getting blocked but it is showing up in the waterfall as a really short load time (with a -2 error) because Chrome thinks it requested it and I blocked it through the extension API. There was a recent change to merge Chrome's view of requests with what I see from the network to better deal with https and SPDY but it looks like it accidentally also picked up the blocked requests.


RE: blocking requests doesn't seem to work - nilskuhn - 06-06-2013 06:42 PM

The request, I want to block is a fake-image to track real-user-monitoring (rum) via Navigation timing api. So the short time and the status of -2 has nothing to do with the blocking by wpt. Local tests with firebug or chrome-developer tools show the same (short) request. Also wpt-tests without block-command show the short-time request with status -2:
http://www.webpagetest.org/result/130606_42_CQF/

With another image the blocking works in chrome:
http://www.webpagetest.org/result/130606_GC_DD6/details/ contains no otto_beta_logo.gif-request
http://www.webpagetest.org/result/130606_EF_DDK/1/details/ contains otto_beta_logo.gif-request


RE: blocking requests doesn't seem to work - nilskuhn - 06-12-2013 10:57 PM

I have to contradict myself:

I can't reproduce status-code of -2 locally in firebug or chrome dev-tools. The ottorum.gif-requests have times of 20-70 ms, but not 0-3 ms like in wpt-waterfalls.

I can reproduce status-code of -2 with a wpt-test without block-command.

So it seems, some mechanism in wpt leeds to status -2 and the short times (and it has nothing to do with the blocking)...