Re: RFC: Stop to automatically cast nu meric-string to int when using them as array-key

On 2 January 2022 03:47:11 GMT, Kirill Nesmeyanov <nesk@xakep.ru> wrote: > >I just gave an example of what at the moment can cause an exception in any application that is >based on the PSR. It is enough to send the header "0: Farewell to the server". In some >cases (for example, as is the case with RoadRunner) - this can cause a physical stop and restart of >the server. Any library where a crafted HTTP request can cause a server shutdown has a bug which needs addressing right now - possibly more than one, actually, as it implies error handling is leaking across request boundaries. A change to the language applied in the next major version would fix this some time around 2025, once people start adopting it. A workaround in the library itself can be applied within weeks. I already gave a simple solution that such libraries can apply right now, with very little chance of negative impact: sanitise headers more aggressively than the HTTP standard requires, as Apache httpd does, in this case discarding any header containing only digits. This is likely to be about three lines of code inside a loop preprocessing raw headers: if ( ctype_digit($rawHeaderName) ) { trigger_error("Numeric HTTP header '$rawHeaderName' has been discarded.", E_USER_WARNING); continue; } If I was the maintainer of such a library, I might consider even stricter validation, considering what seems like an accidentally broad definition in the HTTP spec, and the possibility of an application receiving even more exotic characters if processing raw TCP traffic. The idea of an array_keys variant or option that forces everything back to string seems like it might be useful (and easy to polyfill for old versions). Changing such a fundamental language behaviour in the hope that it will fix more code than it breaks is just not worth it. Regards, -- Rowan Tommins [IMSoP]