File links for paths with reserved characters ( '+' & '#' '?') generated wrong for external streamWrappers.

This came up as a daily BSI target

Is it only possible to replicate with s3? I don't have a free one I can verify with but would be good to check if still an issue.

This bug impacts any streamWrapper that generates FQDN based URL's that are not the local server.

This should include any of following:
s3fs
All Flysystem streamWrappers that are not local (s3, ftp, etc)
remote_stream_wrapper (when used with remote_stream_wrapper_widget)

Quick tested with RSW since I had it open in another lab for a different reason (this would be D10.5 as it has not yet been ported to D11) and it is easier to manipulate the URL's with:

URL: http://www.example.org/test/test%23not_fragment.txt
Rendered: http://www.example.org/test/test#not_fragment.txt

I don't have a free one I can verify with

You might consider the localstack/localstack docker image. S3fs uses this image in all of its GitlabCi runs to emulate a server, not 100% feature complete to AWS S3 however it is sufficient enough for testing the majority of code operations with that streamWrapers will utilize.

Normally I would not expect non-s3fs devs to be setup with a S3 development lab, however as there are multiple S3 contrib modules available and Drupal Core developers could benefit from having at least one external stream wrapper installed in their dev labs to test scenarios it may be worth keeping this in mind as a tool going forward.

Note:
📌 Disallow dangerous filenames e.g. command injection characters Active will likely make this issue harder to test with direct uploads should it ever be merged as it will transliterate 'special' characters masking that there is a flaw in how streamWrapper url's are processed.

remote_stream_wrapper however will likely make a great sample candidate (assuming it is ported to latest versions) as it does not upload a file, yet still creates a managed file entity.