asynchronous - HTTP Response sent before async call returns -

i yet understand behavior of web server thread, if make async call say, database, , return response ( ok ) client without waiting async call return back. first of all, approach ? happen thread made async call , if used again serve request , previous async call returns particular thread. or web server holds thread waiting till async call made, returns. issue many hanging threads open , web server available take more requests. looking answer.

it depends on way http servers works. should cautious.

let's have main event loop taking care of incoming http connections, , workers threads manage http communications. worker thread should considered ready accept new http request management when completly ready that.

in terms of pure http more important thing avoid sending response before having received whole query. seems simple, , it's case. if query body, may chunked body, take time receive whole message. should never send response before, unless it's 400 bad request response, followed real tcp/ip connection closing. if fail so, , have message length parsing issue, fact sent response before end of query may lead security problems. used exploit differences in parsing of messages between server , other http agent in front of server (ssl terminator, reverse proxy, etc), in sort of http smuggling issue. agent, if made response, means had whole message, , can send next message, in fact think part of body.

now if have whole message, can decide send response , detach asynchronous task perform sort of stuff. means:

• you have assume no more output should generated, not try send output request issuer, should consider communication closed
• the worker thread should not receive new requests manage, , hard part. if thread marked available new request, may killed thread manager (you have in nginx or apache request counters associated workers, , killed after reaching limit, create fresh ones). may receive gracefull reload command (usually it's kill), etc.

so start enter zone should know internals of http server, maybe managed you, or not, , changes may appear sooner or later. , start make strange things, leads strange issues, hard reproduce.

uausally best way handle asynchronous tasks, while still being able understand happen, use messaging system. put list of tasks in queue, , parallel asynchronous worker process things theses tasks. track status of theses tasks if need it. same things may apply client, after receiving fast http answer, may need perform ajax status polling task status. , maybe have check status of task in queue send response.

you more control on whole thing.

for me dislike having detached threads, coming strange code, performing heavy tasks without way of outputing status or reporting errors, , maybe preventing nice application stop calls (still waiting strange threads join) not imply killall.