Re: Re: another fix for max_input_vars.

Inline. On Wed, Jan 4, 2012 at 8:02 PM, Rasmus Lerdorf <rasmus@php.net> wrote: > On 01/04/2012 11:54 AM, Nikita Popov wrote: >> On Wed, Jan 4, 2012 at 8:50 PM, Rasmus Lerdorf <rasmus@php.net> wrote: >>> Since it is one of these remotely-triggered errors that you can't >>> program around, it should probably be suppressed when display_errors is >>> on. There is another precedence for this, but I am drawing a blank on >>> where else we did this right now. >>> >>> -Rasmus >> You mean like with htmlspecialchars() before PHP 5.4? Please don't. >> It's really non-obvious to start hiding errors as soon as you enable >> error display. > > But there is a very valid security concern here. People can usually run > safely with display_errors enabled if their code is well-written. They > can check for potential errors and avoid them. This one can't be checked > for and you could easily write a scanner that scoured the Net for sites > with display_errors enabled by sending a relatively short POST request > to each one and checking for this error. And there is absolutely nothing > people could do about this short of turning off display_errors which we > know from experience a lot of people just don't do no matter how much we > suggest it. I agree with Rasmus here. A lot of people keep display_errors on, even when they shouldn't. It log_errors is on, it should go to the error_log, but with display_errors it should never be sent back to the browser. - Paul Dragoonis. > > The alternative is to just not have any error message at all. That > avoids the discrepancy between the error messages with display_errors on > and off. > > -Rasmus > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >