Delay Proxy

Overview

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 208.71.174.227:3007.

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

In Short

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 /settle request.

Selection is done via the URL Contains, 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.

Booking Requests

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 Preferences -> Advanced -> Network -> Settings.

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: 208.71.174.227:3007 but please check on the Book Requests page for the up to date IP and port.

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 http not 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 Summary

The Settings page has a Request and Response section, and each of these are further divided into Selectors and Actions.

Selectors

Content Contains

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 or Doctype won't match)

Has Header

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: Accept-Encoding

To match only requests where a certain header has a certain value, specify both header name and value, separated by a colon: Accept-Encoding:gzip, deflate

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: Accept-Encoding: gzip, deflate
(There's a space before the gzip)

Url Contains

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 auth means that a request to http://test.virtual.blue/auth will have Actions applied to it, while a request to http://test.virtual.blue/settle will not. (By the way the pages http://test.virtual.blue/auth and http://test.virtual.blue/settle do both exist which can be used to help with testing).

Actions

Fixed Delay

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

The default Buffer Length is 1024 bytes.

Further Examples

Fixed Delay

In the 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 & Buffer Length

In the Response section on the Settings page enter a URL Contains value of auth. Specify 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!)

Now load the page http://test.virtual.blue/auth. It looks like our Buffer Delay fired 2 times.

Try altering 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 1000.

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…?