On Sunday, 5 January 2014 at 15:19:15 UTC, H. S. Teoh wrote:
Isn't that usually handled by running the webserver itself as a
separate
process, so that when the child segfaults the parent returns
HTTP 501?
You can do that. The hard part is how to deal with the other 99
non-offending concurrent requests running in the faulty process.
How does the parent process know which request was the offending,
and what if the parent process was the one failing, then you
should handle it in the front-end-proxy anyway?
Worse, cutting off all requests could leave trash around in the
system where requests write to temporary data stores where it is
undesirable to implement a full logging/cross-server
transactional mechanism. That could be a DoS vector.
HTTP link? I rather the process segfault immediately rather than
continuing to run when it detected an obvious logic problem
with its own
code).
And not start up again, keeping the service down until a bugfix
arrives? A null pointer error can be a innocent bug for some
services, so I don't think the programming language should
dictate what you do, though you probably should have write
protected code-pages with execute flag.
E.g. I don't think it makes sense to shut down a trivial service
written in "Python" if it has a logic flaw that tries to access a
None pointer for a specific request if you know where in the code
it happens. It makes sense to issue an exception, catch it in the
request handler free all temporary allocated resources and tell
the offending client not to do that again and keep the process
running completing all other requests. Otherwise you have a DoS
vector?
It should be up to the application programmer whether the program
should recover and complete the other 99 concurrent requests
before resetting, not the language. If one http request can shut
down the other 99 requests in the process then it becomes a DoS
vector.
