When configured for injecting delays, the HTTP protocol proxy works like the following:

1. Make a request upstream
2. If it errors, return immediately
3. If it does not error, sleep for the duration of the fault
4. After that, copy the body to the client.

This approach has the advantage of allowing adjusting the delay to consider the duration of the upstream request. For example, if the delay defined in the fault injection is 500ms and the upstream takes 200ms, the proxy could then wait 300ms. Presently, this is not implemented but would be trivial.

On the other hand, it has the downside of stalling the connection upstream for the duration of the delay. This may have unwanted consequences, such as:

1. Stealing resources from upstream, potentially causing it to behave differently than usual
2. Causing upstream to abort the stalled connection with HTTP 408, which would then be forwarded to the client.

Alternatively, the proxy could sleep before making the requests, but in this case, it would add the delay on top of the delay of the request