Re: [RFC] Deprecations for PHP 8.6
| From: | Sjoerd Langkemper | Date: | Fri, 26 Jun 2026 15:29:43 +0000 |
| Subject: | Re: [RFC] Deprecations for PHP 8.6 | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-131540@lists.php.net to get a copy of this message | ||
On Fri, Jun 26, 2026, at 14:42, Arnaud Le Blanc wrote:
> Can we deprecate the filter only in php://filter URLs, and not in the function-based filter
> API?
Yes. this would be a practical solution that prevents misuse of dechunk in attacks, while still
providing it for legitimate use. It is technically possible, but it won't be a pretty
implementation. It would basically be
if (name==dechunk) raise_error() in the code that
parses the filter URL. It would break the consistency of the filter API.
Perhaps it would be useful to first deprecate and remove dechunk in php://filter URLs and later
deprecate and remove it altogether, but doing only the first without doing the latter would be a
real hack.
An alternative could be to offer http_dechunk() as a function, instead of as a filter, to provide an
easier upgrade path. A more rigorous approach could be to deprecate the whole of php://filter URLs.
Regards,
Sjoerd Langkemper