Re: [RFC] Deprecations for PHP 8.6

From: 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

« previous php.internals (#131540) next »