-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Regression: Caddy 2.9.0 returns 411 Length Required for some sites #6757
Comments
Issue also affects Laravel applications running with Caddy. |
I cannot setup my laravel project using Caddy 2.9.0 |
Same thing happening to my WordPress site. I have only observed this in Firefox though. Downgrading fixed it. |
Add @teddysun 6638 is not the cause, that actually fixes the buffering problem. Revert 6661 and see if it will happen. These two patches are implemented to solve the ddos attacks reported. However, request buffering will be needed if content length is not specified. Any access logs will be appreciated to see if any alternative approaches without enabling explicit request buffering can be done. |
Yes, revert #6661 and problem was solved. |
Ubuntu 22 (ARM), PHP 8.3. |
@teddysun Can you test if |
I am having this issue, but oddly only on a few select servers. Downgrading has not fixed it for me. Tried Firefox and the first request went through, but subsequent ones did not. This is very odd |
Encountered this issue on my basic HTML+CSS+PHP sites. Was fixed by reverting #6661. |
@rwinkhart Can you test if xcaddy build fastcgi_buffer fixes this issue? |
@teddysun @Telesphoreo @dzervelce @Brawl345 @spurgeonbj We know that downgrading fixes the issue; it's already an established regression -- but please notice @WeidiDeng is asking if others can verify whether #6759 fixes it without having to revert and downgrade. If no one experiencing the issue can verify this then we cannot release a patch. Weidi has even provided instructions multiple times now for an easy way to compile Caddy with the proposed patch: |
Yes, I added request_buffers 100m inside my php_fastcgi block and it did fix it. Very weird on why this only happened on one server (regardless of PHP being used for the actual subdomain). I have one local VM that builds caddy with xcaddy and deploying it to all of those went fine. On a few servers that I just update with apt, some had issues and some didn't. They all have the same Caddy configuration. Very weird that downgrading didn't fix it for me, but adding that block did fix it. Edit: The fix did work. You can ignore everything else. I am definitely very tired and have everything mixed up. I did not realize that the caddy add-package command upgraded you to 2.9.0 even though I had downgraded with apt. Basically, all the servers I deployed a self built caddy binary worked. Some upgraded fine with apt, some did not. I realize now that all the inconsistencies were my use of the add-package command on the servers that install caddy from apt. |
@WeidiDeng The build seems to be failing due to an import cycle when I try that. Haven't used xcaddy before (I've just been building with
Edit: Though this could probably be assumed, I thought I should specify that it does build fine without specifying |
I have the same problem. After upgrading from Caddy 2.8.4 -> 2.9.0 the site was broken/unresponsive. I can confirm that after adding
|
After #6759 commit 3ba88fe |
Thanks a ton! #6759 LGTM too! God bless you abundantly in all that concerns you! |
Happy to report that fastcgi_buffer fixes HTTP/3 error 411 problems from nextcloud via HTTP/3 for me. |
I am unable to use xCaddy on my Almalinux 9 server to build with fastcgi_buffer. Instead I tried adding the syntax request_buffers 100m or request_buffers 4k both didn't solved the issue.
All images stopped displaying in WordPress admin before or after I used request_buffers syntax. Difference is that previously it wasn't displaying and after it didn't loaded. |
Thank you to everyone who tested @WeidiDeng's hotfix! (And huge thanks to Weidi for the quick PR.) We will probably rework the details of the patch later but for now it seems like it does the job. |
After upgrading from Caddy 2.8.4 to 2.9.0, Joomla sites started returning HTTP 411 ("Length Required") errors for certain requests. Downgrading to Caddy 2.8.4 resolves the issue, indicating a regression or stricter enforcement of request header handling in 2.9.0.
The problem seems related to:
. Requests that were previously allowed in Caddy 2.8.4 now fail in 2.9.0.
. Joomla relies on rewrites for dynamic routing (e.g., /index.php?{query}). The rewrites still work, but certain requests (possibly POST or other non-GET methods) fail with 411.
Steps to Reproduce:
Configure a Joomla site with the following minimal Caddyfile:
Make a POST request without a Content-Length header:
curl -X POST https://dev.apcwo.org/path -d '' -v
Observe a 411 response in Caddy 2.9.0. The same configuration works in Caddy 2.8.4.
Expected Behavior: Caddy should handle requests without a Content-Length header the same way as in version 2.8.4 or provide clear guidance on how to adapt the configuration.
Observed Behavior: Caddy 2.9.0 returns 411 errors for requests that worked in 2.8.4, breaking Joomla functionality.
Additional Details:
Joomla uses rewrites heavily, and the issue seems tied to how Caddy processes requests during rewrites.
The problem was tested with PHP-FPM and occurs even with minimal configurations.
Caddy logs show no additional details besides the 411 response.
Downgrading to Caddy 2.8.4 immediately resolves the issue.
Environment:
Caddy Version: 2.9.0
PHP Version: 7.4 (PHP-FPM)
Joomla Version: (3.10)
OS: (Ubuntu 20.04)
Suggestions for Debugging:
Review changes in Caddy 2.9.0 related to request handling or HTTP compliance.
Investigate interactions between the rewrite directive and PHP-FPM.
The text was updated successfully, but these errors were encountered: