Bad array indexing is considered deadly

[Paolo Invernizzi via Digitalmars-d]

On Thursday, 1 June 2017 at 18:54:51 UTC, Timon Gehr wrote:
> On 01.06.2017 14:25, Paolo Invernizzi wrote:
>> 
>>> I can detail exactly what happened in my code -- I am 
>>> accepting dates from a given week from a web request. One of 
>>> the dates fell outside the week, and so tried to access a 7 
>>> element array with index 9. Nothing corrupted memory, but the 
>>> runtime corrupted my entire process, forcing a shutdown.
>> 
>> And that's a good thing! The input should be validated, 
>> especially because we are talking about a web request.
>> 
>> See it like being kind with the other side of the connection, 
>> informing it with a clear "rejected as the date is invalid".
>> 
>> :-)
>
> You seem to not understand what happened. There was a single 
> server serving multiple different web pages. There was an 
> out-of-bounds error due to a single user inserting invalid data 
> into a single form with missing data validation. The web server 
> went down, killing all pages for all users.
>
> There is no question that input data should be validated, but 
> if it isn't, the response should be proportional. It's enough 
> to kill the request, log the exception , notify the developer, 
> and maybe even disable the specific web page.

I really understand what is happening: I've a vibe.d server 
that's serving a US top 5 FMCG world company, and sometime it 
goes down for a crash.

It's dockerized, in a docker swarm, and every times it crashes 
(or it's "unhealty") it's restarted, and we've a log, that it's 
helping us to squeeze bugs.

Guess it, it's not a problem for the customer (at least right 
now!) as long as we have taken a clear approach: we are squeezing 
bug, and if process state is signalling us that a bug has 
occurred, we simply pull the plug.

A proportional response can be archived having multiple processes 
handling the requests.. it's the only sane way I can think to not 
kill "all" the sessions, but only a portion.

/Paolo