You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a difference in Content-Length header handling in MF v.2. Let's assume the following proof of concept code:
addEventListener('fetch',function(event){event.respondWith(handleRequest(event.request))})asyncfunctionhandleRequest(request){constresponse=awaitfetch(`http://origin.example.com/whatever.txt`)// eventually we give up on serving original response, and return 403 with empty bodyreturnnewResponse("",{headers: {
...Object.fromEntries(response.headers),
...{"x-workers-hello": "Hello from Cloudflare Workers"}},status: 403,statusText: "Access Denied"})}
We initially go forward but based on some conditional logic, we decide to serve 403 with empty body. The code copies headers from the original response and this is intentional as we want to retain meta information (content-type + some other headers).
Original response contains Content-Length: 1234.
Since we copy all original response headers, the CL one is copied as well.
Now, CF and MF v1.x - they override the CL to 0, MF v2.x doesn't.
When 403 is served with the CL > 0, the user agent is waiting for the payload which never comes in and causes client timeout.
IMO the behavior should be consistent.
The text was updated successfully, but these errors were encountered:
There is a difference in Content-Length header handling in MF v.2. Let's assume the following proof of concept code:
We initially go forward but based on some conditional logic, we decide to serve 403 with empty body. The code copies headers from the original response and this is intentional as we want to retain meta information (content-type + some other headers).
Original response contains
Content-Length: 1234
.Since we copy all original response headers, the CL one is copied as well.
Now, CF and MF v1.x - they override the CL to
0
, MF v2.x doesn't.When 403 is served with the CL > 0, the user agent is waiting for the payload which never comes in and causes client timeout.
IMO the behavior should be consistent.
The text was updated successfully, but these errors were encountered: