411 - Length Required Error for PUT requests with no body

What is the name of the domain?

What is the error number?

411

What is the error message?

411 - Content-Length required

What is the issue you’re encountering

Cloudflare suddenly started to reject PUT requests with no Content-Length header with HTTP error 411.

What steps have you taken to resolve the issue?

Turning the proxy off resolves the issue, but this is not a solution.

Also including a Content-Length header with value of 0 fixes the problem, but this is not a solution either for third-party requests.

What are the steps to reproduce the issue?

Send a PUT request with empty body and no Content-Length header.

This was never an issue up until this Tuesday (15 April). Since then Cloudflare started to reject PUT / POST requests with no body. Some libraries do not include the Content-Length header when the request lacks a body, and this is a valid scenario. So Cloudflare should just continue to forward these requests to origin, instead of rejecting them with 411.

I can’t replicate this, both post and put requests without the header make it to my server.

Can you share the full response headers of a 411 request?

Do you use IIS?

Yes, the origin servers run on IIS. And that works fine if the requests hit those directly. However origin servers are proxied through Cloudflare, and this is where we’re getting the 411 errors.

Here are the response headers:

Date: Thu, 17 Apr 2025 10:47:54 GMT
Content-Type: text/html; charset=us-ascii
Transfer-Encoding: chunked
Connection: keep-alive
Server: cloudflare
Cf-Cache-Status: DYNAMIC
CF-RAY: 931b58d57dc33161-LHR
alt-svc: h3=“:443”; ma=86400

Thank you.

DYNAMIC means the error is coming from your server.

Im not familiar with IIS, but someone else had the same problem some time ago, and it turned out the requests were blocked by http.sys, which is a part of IIS or Windows server maybe?

I can search for the topic in a few minutes.

Here’s the other topic, but I’m afraid it doesn’t really have more info:

And don’t take this wrong, it might still be related to a recent Cloudflare update, but the logs from the server side might help narrow down where the problem lies.

Thank you!

That post was spot on! Indeed the HTTPERR log contains all the requests refused with 411.

I’ll have a look what might have changed (if anything) on our end.

1 Like

I have the same problem…
Suddenly cloudflare proxied api endpoint (PUT) started to return 411 Length Required error (for empty body PUT, with Content-Length: 0). It works fine without proxy (I can use direct url and it works), I did not change anything regarding backend (GCP Cloud run) and cloudflare. I don’t see the traffic in my backend access logs, that’s why it seems cloudflare blocked the request

Did you find anything in the logs that might help other users?

No, it seems the errors in HTTPERR are intermittent. Most of the time nothing landed in there, so I assumed Cloudflare proxy is doing some magic. Meanwhile we patched the code that is under our control to send an empty JSON as body - {}, instead of an empty body. And hoping the issue will go away on its own, the same way that it appeared :slight_smile:

1 Like

Could you share the server ip with me (via pm) so I can try to figure out what’s different in the requests from users and via Cloudflare?

I’d like to figure out if it is related to a recent CF update. Is this on a free CF plan?

Yes, it’s for a domain on a free Cloudflare plan. I’ll share the IPs with you in a minute, thanks.

I can’t find a way to send a PM :expressionless:

Hi! We are facing the same problem. It started to occur recently. Symptoms are the same: when browser or any other http client (we tried curl) sends POST or PUT request with empty body and a header content-length: 0 and this request is reverse-proxied by Cloudflare to our server, the header content-length: 0 disappears. Our web server is IIS which runs on Windows Server. This request can’t reach it, because it is denied by HTTP.SYS which replies with 411 Length Required.
The only thing we figured out is that this problem depends on used HTTP protocol version. Our web server supports HTTP/2 and HTTP/1.1 protocols. So, when the client sends request using HTTP/3, Cloudflare transforms request to our server using HTTP/2 and this works fine, the header remains in place. But when we try to send request using HTTP/2 the header disappears. Here are our test commands:
This one works fine:

curl -v -X PUT -H "Content-Length: 0" "https://our-site-url" --http3

These two returned 411:

curl -v -X PUT -H "Content-Length: 0" "https://our-site-url" --http2
curl -v -X PUT -H "Content-Length: 0" "https://our-site-url" --http1.1

We clearly see in verbose output that content-length header was supplied:

* [HTTP/2] [1] OPENED stream for https://our-site-url
* [HTTP/2] [1] [:method: PUT]
* [HTTP/2] [1] [:scheme: https]
...
* [HTTP/2] [1] [user-agent: curl/8.13.0]
* [HTTP/2] [1] [accept: */*]
* [HTTP/2] [1] [content-length: 0]
> PUT /our-site-url HTTP/2
> Host: our-host
> User-Agent: curl/8.13.0
> Accept: */*
> Content-Length: 0
>
* Request completely sent off
< HTTP/2 411
< date: Thu, 24 Apr 2025 17:04:11 GMT
< content-type: text/html; charset=us-ascii
< server: cloudflare
< cf-cache-status: DYNAMIC
< cf-ray: 93572da9efe621d7-AMS
< alt-svc: h3=":443"; ma=86400
<
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Length Required</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>
<BODY><h2>Length Required</h2>
<hr><p>HTTP Error 411. The request must be chunked or have a content length.</p>
</BODY></HTML>

There are no other proxies between our client and server except Cloudflare.

1 Like

Thanks for the detailed report!

I’ll try to reproduce this in a moment and will ask someone from CF to take a look.

Is the problem occuring on free or paid for you?

We are using free plan on that server

Here’s some additional observations:

  1. At this time problem affects PUT requests only. All POSTs with empty body work fine.
  2. We reproduced this issue on 3 different servers with different domains. All of them are on free plan.
1 Like

This topic was automatically closed after 15 days. New replies are no longer allowed.