> I can't find any information on why this setting was introduced. No, I couldn't find anything either. I did try to investigate and all I could find was that it was introduced by Joe Watkins in 0819e6dc9b4788e5d44b64f8e606a56c969a1588 in 2019 but I haven't been able to find any history of RFC or discussion about it.
> I guess that it was either to protect sensitive information or to reduce > verbosity in the logs, but either one seems like a poor reason for > this setting to exist. The INI comment seems to suggest that it was > introduced to protect sensitive information, but that doesn't make > sense to me since exceptions aren't revealed to the end user. In an ideal world they are never revealed to the end user, but real-world solutions fall short. It's not uncommon for people to have display_errors enabled for some reason or another. It is also possible for sites to be misconfigured, or for applications to make mistakes and accidentally dump stack traces without realising that they may contain arguments. Not all applications make use of an error handling framework, and people may enable display_errors without understanding the ramifications. Ultimately developers and administrators are all human (for now). We can, and do, make mistakes. PHP is already capable of preventing information leakage from such mistakes, but it is currently not the default configuration. Let's make it the default. This does not stop people who have actively configured stack trace arguments from having access to those args. > And while verbose, arguments in stack traces are useful. On top of that, > it seems to me like this is already covered by > exception_string_param_max_len. If you set the length to 0, isn't it > the same as setting exception_ignore_args to On? Or does that mean > that no truncation is applied? Completely off the top of my head, it is probably still worth having both. A configurable max length isn’t the same as a simple on/off toggle that can be flipped directly in code. The max length was actually introduced later by Tyson Andre in 07db64156e180c30daa5ab5d41ed72f9bba77e6d in 2020 and discussed here: https://externals.io/message/110717 >From the look of the commit it _only_ applies to the `getTraceAsString()` method, and not `getTrace()`. It was intended to allow more information to be dumped than the previously hard-coded 15 bytes. Even setting it to 0 doesn’t consistently remove args — e.g., getTrace() still includes them, so merging these two is not really a clear or easy solution. > I suppose if this INI setting must exist, then it should be set to Off in > both development and production environments. Can you elaborate? Setting it Off by default increases the risk of accidental information leakage when apps aren’t correctly configured. That's great for developers, but for production sites that's not a good idea. There is no way to guarantee that every PHP application is a perfect, well-configured, system which uses the latest frameworks. Many of us are dealing with massive legacy codebases. Where a framework correctly configures error handling, and determines that it needs the arguments as part of that, it is surely able to also call `ini_set('zend.exception_ignore_args', 0)` at the same time as it configures that error handler. > The max length should probably be increased, too. I would also appreciate it > if it gets > clarified in the documentation why the two settings exist and what the > difference between them is. And I wouldn't object to removing > exception_ignore_args if it's a redundant setting. I agree it would be good to clarify this, but I don't think that either should be removed. Reading the Internals discussion for the length makes it a little clearer as to why it exists and why they're separate. I'd suggest that this can be done via PR process without need for an RFC. In any case, I would strongly object to removing `exception_ignore_args`. It is not a redundant setting and it is critical to many in production. > P.S. The RFC mentions execution_ignore_args too, but I assume that's a typo. Thanks - I'll fix that. On Fri, 11 Apr 2025 at 04:04, Kamil Tekiela <tekiela...@gmail.com> wrote: > > I can't find any information on why this setting was introduced. I > guess that it was either to protect sensitive information or to reduce > verbosity in the logs, but either one seems like a poor reason for > this setting to exist. The INI comment seems to suggest that it was > introduced to protect sensitive information, but that doesn't make > sense to me since exceptions aren't revealed to the end user. And > while verbose, arguments in stack traces are useful. On top of that, > it seems to me like this is already covered by > exception_string_param_max_len. If you set the length to 0, isn't it > the same as setting exception_ignore_args to On? Or does that mean > that no truncation is applied? > > I suppose if this INI setting must exist, then it should be set to Off > in both development and production environments. The max length should > probably be increased, too. I would also appreciate it if it gets > clarified in the documentation why the two settings exist and what the > difference between them is. And I wouldn't object to removing > exception_ignore_args if it's a redundant setting. > > P.S. The RFC mentions execution_ignore_args too, but I assume that's a typo.
