Problem/Motivation
If a file url has query parameters, or a hash, added to it. The file-link component strips these out.
Drupal would not normally use query parameters on a file url. But in our case they are being added in by a stream wrapper, from the flysystem_s3 module (we are using them to pass through a url signature, to allow the user access to the file).
Query parameters could also be added in by hook_file_url_alter(), these would again be stripped out.
The core public file stream wrapper url encodes any query parameters added by hook_file_url_alter(). So these the are retained.
The issue is caused by the new file handling in template_preprocess_file_link(), which used to create the Url object itself, but now uses the new file_url_generator service. Since this changed was introduced, the $options is being overwritten by $url->setOptions($options)
Steps to reproduce
Proposed resolution
Use
$url->mergeOptions($options)
Instead of
$url->setOptions($options)
Comments
Comment #2
leon kessler commentedAdding patch that switches to using
$url->mergeOptions($options)Looking at writing a test for this, adding something to FileFieldWidgetTest.php and then using hook_file_alter() to add in the query parameter.
Comment #3
leon kessler commentedDoes not appear to be an issue for hook_file_url_alter() with the default public stream wrapper. As this url encodes query parameters (before they are parsed
FileUrlGenerator::generate).So this issue is more specific to third party stream wrappers, and really it's only relevant for externally hosted files (e.g. on S3/CDN, etc). As Drupal would not be using query parameters on files anyway.
Comment #4
leon kessler commentedI've worked up a test to demo the issue. This depends on the dummy-external-readonly stream wrapper from #3254553: FileUrlGenerator::generate() does not work with externally hosted files using stream wrappers (so I've now made this a child issue).
It's admittedly a bit of an edge case, so was quite difficult to find a nice place for the test to live.
Comment #5
leon kessler commentedPrevious patch was in the wrong file. New patch should run correctly and produce 1 failure.
Comment #6
leon kessler commentedHere's a patch with the tests + the fix. This should pass.
It's also dependent on the fix from the parent issue (otherwise the query string gets url encoded). So this is also combined into the patch to allow it to pass. Have created an interdiff to show the changes related to this issue.
Comment #8
andileco commented#6 worked for me to fix this issue: https://www.drupal.org/project/s3fs/issues/3254464
Thank you for the patch!
Comment #9
leon kessler commentedRe-rolling the combined patch with updates from parent issue.
The interdiff from my comment on #6 (between this patch and the parent patch) is the same).
Comment #10
ranjith_kumar_k_u commentedComment #11
rokzabukovec commentedThe patch from #10 fixed the malformed URL issue only when uploading a new media item/file. When I try to view the node the error is back. I'm on Drupal core 9.3.2.
Comment #12
leon kessler commented@rokzabukovec This isn't happening for me, the file url on the "Generic file" formatter has the correct url. Possibly you are using another formatter or theme function?
Comment #13
cmlaraTested against s3fs with presign url's which would generate option parameters and it solved the faults. Unable to duplicate concerns from #11, I also suspect it is another formatter or theme function.
RTBC #10 so long as the parent issue remains at patch #20.
May need a trivial rebase after the parent is committed.
Comment #14
leon kessler commentedNow that the parent issue has been pushed to 9.3.x, here's a re-roll of the patch, with just the changes for this issue.
Not sure if this needs to go back to "needs review"? There are no changes since the last patch.
Comment #15
cmlaraI’m still good with RTBC from me.
Same patch with expected patent issue code removed now that it was committed.
Comment #16
cmlaraMoving to major on the grounds it interferes with a normal site visitors’ use of the site.
Use cases where this is an issue can cause inability to access content (s3 presigned urls.)
Comment #18
cmlaraI don't see how this patch could be at fault for this.
#2829040-142: [meta] Known intermittent, random, and environment-specific test failures also reports random issues around this test.
Back to RTBC as I believe this is a random failure.
Comment #22
catchCommitted/pushed to 10.0.x, cherry-picked to 9.4.x and 9.3.x, thanks!