Problem/Motivation
content-length is set in a Response kernel event. But http_middleware services come later. Page cache is one example of a middleware. In the case of it, it doesn't alter the response. But until now, nothing stopped a middleware from altering the response. This messes up sites that are using any middlewares that do just that.
Steps to reproduce
Proposed resolution
Instead of setting content length in a kernel event, set it later in a http middleware.
Remaining tasks
User interface changes
API changes
Change notice https://www.drupal.org/node/3298551 should be updated explaining some of the implications related to adding the content length to HTTP headers.
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 3410022.patch | 5.61 KB | heddn |
Issue fork drupal-3410022
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3410022-regression-from-3295790
changes, plain diff MR !5920
Comments
Comment #2
heddnComment #3
heddnI'm able to confirm that this is a regression. If I remove the content length header from
HtmlResponseBigPipeSubscriberandFinishResponseSubscriber, then everything starts working again. This breaks https://www.drupal.org/project/tailwindcss_utility, which has a http_middleware service.Comment #4
heddnWhile looking at things, I wonder if we need to also alter the Cors middleware to a lower weight. It would also adjust the content length. For now, leaving alone. This just gets the conversation started.
Comment #5
smustgrave commentedAdding some needed tags
Comment #6
bradjones1Should also be an MR at this point.
Comment #11
heddnConverted to an MR and a failing test added.
Comment #12
heddnUpdating tags
Comment #13
catchThis will conflict with #3396559: Only set content-length header in specific situations but it might fix any remaining issues related to the change.
Comment #14
larowlanComment #15
heddnI'm happy to rebase this if the other one goes in first.
Comment #16
larowlanReworked after #3396559: Only set content-length header in specific situations
Comment #17
mstrelan commentedComment #18
catchThis is tempting, but I like the separate middleware too, seems a bit more explicit.
Can't see anything to complain about here, so moving to RTBC.
Comment #19
longwaveThree tests failed, two of them in BigPipe, don't recognise them as randoms so triggered a retest but if they fail again there are more problems to fix here.
Comment #20
longwaveYup,
AssetOptimizationTestUmami::testAssetAggregationand two of the BigPipe tests fail consistently.Comment #21
catchPushed a commit for that - priority is highest first, it was using them like weights.
Comment #22
heddnFor me, this is RTBC again if the tests pass green.
Comment #25
longwaveCommitted and pushed 8f0872276e to 11.x and 257ca110a6 to 10.2.x. Thanks!
Also updated the change record at https://www.drupal.org/node/3298551 to reflect the new way of doing this, would appreciate it if someone can double check my work there.
Comment #26
heddnchange record looks good to me.
Comment #27
andypostPlease close the MR
Comment #29
godotislateNot sure whether to post a follow up against Drupal core or drush, but after this commit, I'm seeing exceptions being thrown when I run
drush updb. Database updates via web UI work just fine. Drush version is 12.4.3.0.Steps to reproduce:
drush updbComment #30
catch@godotislate maybe both so we can track it from each side?
Does it work if you remove the
finalfrom ContentLength?Comment #31
godotislateWill do.
Yes, no exceptions thrown.
Comment #32
godotislateFollow up: #3412160: Uncaught exception thrown when running database updates via drush
Drush issue: https://github.com/drush-ops/drush/issues/5848
Comment #33
heddnI've run into this before w/ drush on some other un-related operations. It assumes everything is non final and tries to wrap objects in its own wrapper via reflection. In the past we had to check for if the object was final. I wonder if that is what is happening here. The obvious thing is to not make the class final. But its awful convenient for a simple class like we have here to make it final and not need to worry about BC.
Comment #34
larowlanComment #36
grimal commentedHi,
I've encountere this issue after updating from version 10.1 to 10.2.3 on an OVH hosting platform (although everything it's fine in my local env).
While the page does render in the browser, it continues to load for approximately 5 seconds.
Upon testing the request with CURL, I observed that the HTML content is sent, but then there's a delay of 5 seconds before it returns the error: "curl: (18) transfer closed with 16932 bytes remaining to read". The CURL request executes without issue when the --compressed option is omitted.
To resolve this, I've removed 'Content-Length' header with $response->headers->remove('Content-Length') before calling $response->send() in the index.php file.
Any idea why I'm still experiencing this issue with Drupal 10.2.3, despite it should be fixed?
Comment #37
phily@grimal: see #35 at issues 3419024 where the suggested addition to .htaccess file might help you.
Header always unset Content-Length