The request expiry work with unit tests. #819
Conversation
|
@yunong this should do it |
Importanttravis-ci is not claiming bad builds when unit tests fail. This is because make is not catching the exit 1 condition from node unit on a test case failure. |
| @@ -1081,6 +1082,21 @@ Options: | |||
|
|
|||
| Note that `ip`, `xff` and `username` are XOR'd. | |||
|
|
|||
| ### Request Expiry | |||
|
|
|||
| Request expiry is used to kick out old requests that have been timed out somewhere upstream. | |||
There was a problem hiding this comment.
I might change the prose here to something a bit more succinct, like.
"Request Expiry can be used to throttle requests that have already exceeded their client timeouts. Requests can be sent with a configurable client timeout header, e.g. 'x-request-expiry-time', which gives in absolute ms since epoch, when this request will be timed out by the client.
This plugin will throttle all incoming requests via a 504 where 'x-request-expiry-time' < Date.now() -- since these incoming requests have already been timed out by the client. This prevents the server from processing unnecessary requests."
| * A request expiry will use the headers to tell if the | ||
| * incoming request has expired or not. The header is | ||
| * expected to be in absolute time since the epoch. | ||
| * @param {Object} options |
There was a problem hiding this comment.
Can you add a description of what options is and also add @param {string} options.header with a description?
|
ok, how about now @yunong ? |
The request expiry work with unit tests.
No description provided.