Hi On Tue 28. 7. 2026 at 10:59, Pierre Joye <[email protected]> wrote:
> Hey Matteo, > > On Tue, Jul 28, 2026 at 2:36 PM Matteo Beccati <[email protected]> wrote: > > > > Hi Pierre, > > > > Il 28/07/2026 05:52, Pierre Joye ha scritto: > > > For example, Symfony's native http client disable it by default as it > > > fails/failed to work correctly with stream_select, according to the > > > inline comment in > > > > https://github.com/symfony/symfony/blob/bb5999123482057647a0831010d14b6b34fe443c/src/Symfony/Component/HttpClient/NativeHttpClient.php#L227 > > > > FYI, Symfony has implemented a pure-PHP alternative in 8.2: > > > > > https://github.com/symfony/symfony/commit/dca372b185100e82c556a741a96cbae1538162f2 > > > > That's why your search pointed in the wrong direction. Pre-8.2 there are > > a couple of: > > > > stream_filter_append(..., 'dechunk', \STREAM_FILTER_WRITE); > > > > in the code, if for whatever reason the Curl client is not in use. > > > > > > > I would go with keeping that deprecation, and if anything went off the > > > radar, the major frameworks components will surely, or hopefully, > > > provide the feedback required to revisit this deprecation before RC1. > > Yet, feedback on how to improve/mitigate was provided and ignored during > > the discussion period. Avoiding the deprecation on > > stream_filter_append(), as suggested, would have been nice. > > Thanks :) > > I miss the 8.2 switch. That being said, deprecation is for php 9 > removal as a target ideally. Keeping stream_filter_append that brings > little to support users to migrate to a final solution earlier. Half > baked deprecation can lead to missing places where implementation > should be updated This is exactly a half baked deprecation because we need to keep it for internal use anyway (it’s used http stream wrapper for chunked encoding) so this does not give us any code removal and we still need to maintain it. I don’t understand why we need to rush it as there is no real reason for that. Also we cannot just decide not to deprecate it in RC. We would need extra approval from RM and then new RFC. We had exactly this sort of situation last year with __sleep and it was huge pain to change. It also took lots of our time that we could use for much more important stuff. Kind regards, Jakub
