Our Delay Proxy is a free proxy service for testing how delays and timeouts on external requests can affect your application. Delays can be added selectively, based on the target URL, the headers or the content – for example you could test adding a delay to www.example.com/settle_payment but let the call to www.example.com/authorise_payment go through without delay.
As this example suggests, this web application is well suited to testing timeouts of requests to external payment services. However, it can be used in many other situations where it is desirable to find out the effect of a delay or timeout on an external request.
Warning: Presenting this software as a web application is experimental and it’s survival will depend on it’s continued use for legitimate testing purposes. We are all too aware that proxies in general are often the target of abuse. If at any point we deem this project to be too much of a safety concern we will take it down, potentially without issuing prior notice.
*Additional Disclaimer: This application is presented without any warranty. Use it at your own risk. We cannot be held liable for any accident or loss which may be incurred through it’s use.
On a more positive note – this service is free, and we want to keep it that way. Help us improve it by providing feedback: what would make this service better for you? get in touch and tell us what you think.
You can link to the application here, but please read the rest of this documentation to prevent unexpected behaviour (or your IP being blocked!)
The Delay Proxy comprises 2 parts, which you can essentially think of as corresponding to the request and response part of an http cycle.
You book requests by specifying the source IP address (ie the IP address where the requests will originate) through the web interface. Then instruct your application to proxy via the Delay Proxy URL. This is currently
Your booking allocation will deplete each time you make a request through the proxy. But its simple to book further requests, and there is no limit to how many times you can do this. The maximum number of requests you can book at a time is displayed on the Book Requests page of the app.
Note that only requests using the
http scheme will be accepted.
https requests will be denied access. This is because with https the proxy would not be able to see the request information, so it would not be able to selectively add delays to your requests. If you are wanting to test an app which normally uses https, we suggest you disable https for the purposes of timeout testing. (If the data you are using for testing is sensitive, we suggest this is probably not really test data at all).
You can target requests to delay by one or more of the following methods
matching a string of characters in the request url
requiring one or more request (or response) headers to be present
matching a string of characters in the request (or response) content
The Delay Proxy sits between your calling application and the target server. You can route all your app requests through the proxy, but select out only specific ones to apply a delay to. You can make this selection by specifying the target URL, one of the headers, or a string to match in the request or response content. So for example, you could let an
/authorize request go through without a delay, but add a delay to a
Selection is done via the
Has Header and
Content Contains selectors. Selectors act to narrow the selection, so leaving all selectors blank will effectively select all requests/responses. Specifying e.g.
auth in the
URL Contains field will result in only those requests with the word “auth” somewhere in the URL being selected.
To get started, visit the Booking page. The first step is to book some requests. This basically means telling the proxy to permit requests made from whichever IP you specify.
You’ll also need to configure your app to use the proxy listed on the Booking page. For this example, our “app” will simply be a web-browser – specifically Firefox. This can be done in Firefox via
In the HTTP Proxy field, enter the proxy and port found on the Book Requests page of the app. At the time of writing, this is:
On the Book Requests page you’ll see a field to enter the source IP address (ie the address where your requests are going to originate
Enter the number of requests you want to book. At the time of writing you can book 12 requests, but please consult the app front page as this number is subject to change.
Then type in the captcha and click
Book Requests. Wait a few seconds for the requests to process. Once processing has completed, you should see a table showing the IP address you entered and the number of requests you booked.
Booked requests are tied to your browser session, so it’s important not to close your browser, or you will no longer be able to see the requests you booked. Requests deplete as you use them, so remember to top up before you run out – or you’re app will get a 403 (forbidden) response.
A Note About Blacklisted IPs
Due to concerns about misuse we have been quite strict with our security requirements, forbidding any source IP addresses which are found on pretty much any public blacklist. Unfortunately this does end up being quite a lot of IP addresses – since a great many IP addresses have been used for nefarious purposes at some point in their history.
If, during booking, you get a message complaining that your IP appears on a public blacklist, please contact us and we can unblock your IP. We don’t want to discourage legitimate use of this service.
Making and Viewing Requests
One way to quickly test the proxy functionality is to use two different browsers – for example Firefox and Chrome. In the example I’ll use Chrome to manage the GUI interface, and we already set up Firefox to act as the calling application (see “Booking Requests” above), routed through the proxy.
I book my requests using the Chrome browser (which is not proxied), choosing my own IP address as the source. (Note the IP address field requires entry of 4 separate numbers – but you can also right click on the field to paste in a full IP address, or choose the source IP address to be the same as the one you are using to view the GUI.)
Make sure the request you use is
https. Since not many ordinary web pages are
http these days, a page has been added at http://test.virtual.blue to make testing easier.
If you load http://test.virtual.blue in Firefox, then navigate to the
Events page in Chrome, you should see something resembling the screenshot below.
You should see 2 events, a request and response. Click on an event to drill down to details about that specific event.
Settings page has a
Response section, and each of these are further divided into
Match the request or response that contains the specified string somewhere in the content. So for example if my
Content Contains field in the
Response section of
Settings has the value
DOCTYPE then the proxy will apply actions to responses that contain the word
DOCTYPE (case sensitive, so
Doctype won’t match)
Match the request or response that has the specified header.
In the next screenshot, you can see I have a selector matching the
Accept-Encoding:gzip,deflate header, and I have set this to trigger a fixed delay of 500ms.
There are 2 ways to use the
Has Header selector. To select all requests that have a certain header, just enter the header name in the
Has Header field:
To match only requests where a certain header has a certain value, specify both header name and value, separated by a colon:
Note the matching algorithm is fussy about spaces – extra spaces added after the colon will be interpreted as part of the header value. Thus specifying the following would not match our request:
(There’s a space before the
Match only requests or responses that have the specified string in the target URL. For example, setting the
URL Contains value in the
Request section of the Settings page to
Delay the request or response by a fixed amount. This is probably the most common action for testing timeouts. For example, setting a fixed delay of 60000 ms (ie 60 seconds) will cause a timeout in many browsers. Whether your app times out will depend how it is configured. (And this is what you’re testing, right?)
If you are calling an external service, you might want to test what happens if the request makes it to the external service, but the response doesn’t get back to your app (so add the delay to the response) – or you might want to see what happens when the service doesn’t receive your request at all (so add a delay to the request).
Buffer Length and Buffer Delay
These are 2 separate fields
Buffer Length and
Buffer Delay but are packaged together because
Buffer Length isn’t really an action in it’s own right; it is the combination of the two values which provides the effect.
Buffer Length and
Buffer Delay provide a way to spread the request out, inserting delays between chunks of data as they are fed through the proxy. This can be used to approximate a bottleneck situation where a slow connection is resulting in intermittent byte throughput. This situation can have a significantly different effect on an application, because at a low level, timeouts really occur when the measured gap between data packets exceeds a certain value – not because the duration of the overall request is too long. Thus it is possible to create requests which take a very long time to execute, but don’t cause a timeout. (Or do they? That’s what you can test here!)
Buffer Length is the number of bytes to process before inserting a
Buffer Delay (in ms). So specifying a
Buffer Length of
512 (that’s 512 bytes), and a
Buffer Delay of
200 would result in 512 bytes throughput followed by 200 ms delay, followed by 512 bytes, followed by a 200 ms delay… and so on until all the request data has fed through.
One important caveat: buffering only applies to the content part of the request or response. The headers are not buffered. Remember in particular that a
GET type request has no content – so adding a buffer delay to this will have no impact at all. (In our example using the web browser, which sends a
GET request when you type in the URL, you would need to add the buffer delay to the response (rather than the request) to see an effect.
Buffer Length is 1024 bytes.
Request section of
Settings enter a
Fixed Delay of
1000 and save. This creates a 1000ms delay, or one second.
Refresh http://test.virtual.blue in Firefox. It will take an additional second for the page to refresh fully, a result of our one second delay. In
View Events, you should also see an elapsed time of just over a second on the request.
The effect will happen on every request, regardless of the target URL, headers or content, because we left all the
Selector fields blank.
URL Contains with Buffer Delay and Buffer Length
Response section on the Settings page enter a
URL Contains value of
500 for the
Buffer Delay and
32 for the
Buffer Length. (We need to specify a short
Buffer Length to see the effect, because the html page we are going to request is short!)
Buffer Delay and
Buffer Length and observe the change in elapsed time?
Now try requesting http://test.virtual.blue. This time you should find no delay is triggered, because the
URL Contains selector does not match.
Content Contains with Fixed Delay
At the time of writing, visiting http://test.virtual.blue/ displays the text
Home Test Page. In the
Response part of the Settings page change the
Content Contains value to
Home Test Page, and add a
Fixed Delay of
Visit the url http://test.virtual.blue/ in Firefox (or whichever browser you are proxying with). You should find that
content_contains on the event detail page has a value of
PASS. Notice the
overall field also has the value
Event matched criteria.
You should be able to see from the elapsed time that the response took just over 1 second.
Now try spelling
Home Test Page incorrectly in
Content Contains. What happens…?