Simple module for delaying a response, optionally with long-polling support
A fast and easy way to delay a response until results are available. Use this module to respond appropriately with status HTTP 202 Accepted when the result cannot be determined within an acceptable delay. Supports HTTP long-polling for longer delays, ensuring the connection stays alive until the result is available for working around platform limitations such as error H12 on Heroku or connection errors from aggressive firewalls.
Note: This module is purely experimental and is not ready for production use.
npm install http-delayed-response
To run the tests:
This module has no dependencies.
For simplicity, all examples are depicted as Express middleware.
This example waits for a slow function indefinitely, rendering its return value into the response. The
wait method returns a callback that you can use to handle results.
// let's do something that could take a while...appusevar delayed = req res;slowFunctiondelayedwait;;
Same thing, except the function returns a promise instead of invoking a callback. Use the
end method to handle promises.
appusevar delayed = req res;delayedwait;var promise = slowFunction;// will eventually end when the promise is fulfilleddelayedendpromise;;
Use the "done" event to handle the response when the function returns successfully within the allocated time. Otherwise, use the "cancel" event to handle the response. During a timeout, the response is automatically set to status 202.
appusevar delayed = req res;delayedon'done'// slowFunction responded within 5 secondsresjsonresults;on'cancel'// slowFunction failed to invoke its callback within 5 seconds// response has been set to HTTP 202reswrite'sorry, this will take longer than expected...';resend;;slowFunctiondelayedwait5000;;
If the function takes even longer to complete, we might face connectivity issues. For example, Heroku aborts the request if not a single byte is written within 30 seconds. To counter this situation, activate long-polling to keep the connection alive while waiting on the results. Use the
start method instead of
wait to periodically write non-significant bytes to the response.
appusevar delayed = req res;// verySlowFunction can now run indefinitelyverySlowFunctiondelayedstart;;
Long-polling is continuously writing spaces (char \x20) to the response body in order to prevent connection termination. Remember that using long-polling makes handling the response a little different, since HTTP status 202 and headers are already sent to the client.
You are responsible for writing headers before enabling long-polling. If the return value needs to be rendered as JSON, set "Content-Type" beforehand, or use the
json method as a shortcut.
appusevar delayed = req res;// shortcut for res.setHeader('Content-Type', 'application/json')delayedjson;// start activates long-polling - headers must be set beforeverySlowFunctiondelayedstart;;
When long-polling is enabled, use the "poll" event to monitor a condition for ending the response. This example polls a MongoDB collection with Mongoose until a particular document is returned. The resulting document is rendered in the response as JSON.
appusevar delayed = req res;delayedjsonon'poll'// "poll" event will occur every 5 secondsModelfindOne /* criteria */if err// end with an errordelayedenderr;else if result// end with the resulting documentdelayedendnull result;;start5000;;
By default, the callback result is rendered into the response body. More precisely:
undefined, the response is ended with no additional content
Buffer, it is written as-is
It is possible to handle the response manually if the default behavior is not appropriate. Be careful: headers are necessarily already sent when the "done" handler is called. When handling the response manually, you are responsible for ending it appropriately.
appusevar delayed = req res;delayedon'done'// handle "data" anyway you want, but don't forget to end the response!resend;;slowFunctiondelayedwait;;
To handle errors, use the "error" event. Otherwise, unhandled errors will be thrown. Timeouts that are not handled with a "cancel" event are treated like normal errors. When using long-polling, HTTP status 202 is already applied and the HTTP protocol has no mechanism to indicate an error past this point. Also, when handling errors, you are responsible for ending the response.
appusevar delayed = req res;delayedon'error'// handle error here// timeout will also raise an error since there is no "cancel" handler;slowFunctiondelayedwait5000;;
Errors can also be handled with Connect or Express middleware by supplying the
next parameter to the constructor.
appusevar delayed = req res next;// "next" will be invoked if "slowFunction" fails or take longer than 1 second to returnslowFunctiondelayedwait1000;;
By default, a response is ended with no additional content if the client aborts the request before completion. If you need to handle an aborted request, attach the "abort" event. When handling client disconnects, you are responsible for ending the response.
appusevar delayed = req res;delayedon'abort'// handle client disconnectionresend;;// wait indefinitely - client might get bored...slowFunctiondelayedwait;;
By default, when using long-polling, the connection is kept alive by writing a single space to the response at the specified interval (default is 100msec).
appusevar delayed = req res;// write a "\x20" every second, until function is completedverySlowFunctiondelayedstart1000;;
An initial delay before the first byte can also be specified (default is also 100msec).
appusevar delayed = req res;// write a "\x20" every second after 10 seconds, until function is completedverySlowFunctiondelayedstart1000 10000;;
To avoid H12 errors in Heroku, initial delay must be under 30 seconds and at least 1 byte must be written every 55 seconds. See https://devcenter.heroku.com/articles/request-timeout for more details.
To manually keep the connection alive, attach the "heartbeat" event.
appusevar delayed = req res;delayedon'heartbeat'// anything you need to do to keep the connection alive;verySlowFunctiondelayedstart1000;;
DelayedResponse instance. Parameters represent the usual middleware signature.
Returns a callback handler that must be invoked within the allocated time represented by
The returned handler is the same as calling
Starts long-polling for the delayed response, sending headers and HTTP status 202.
Polling will occur at the specified
interval, starting after
Returns a callback handler, same as
Stops waiting, sending the contents represented by
data in the response - or invoke the error handler if an error is present.
Stops monitoring timers without affecting the response.
Shortcut for setting the "Content-Type" header to "application/json". Returns itself for chaining calls.
end is invoked without an error. If this event is not handled, the callback result is written in the response.
end is invoked with an error. If this event is not handled, the error is thrown as an uncaught error.
end failed to be invoked within the allocated time. If this event is not handled, the timeout is considered a normal error that can be handled using the
Fired when the request is closed.
Fired continuously at the specified interval when invoking
Fired continuously at the specified interval when invoking
start. Can be used to override the "keep-alive" mechanism.
The MIT License (MIT)
Copyright (c) 2013, Nicolas Mercier
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.