I'm assuming that the OP is using a signed request and the fact that Chrome rewrites the request is what is causing the 403.
I'm interested in what kind of application depends on this behavior - if an application gets partial data from the server, especially one that doesn't match the content-length header, that should always be an error to me.
Some authentication schemes have a short-lived "authorization token", that is valid for like 5 minutes, and a longer-lived "refresh token", which is valid for like a week or two; and return a 403 when the authorization token expires to prompt the client to refresh the token. (See say, supertokens.com .) If your auth token expired in the middle of a multi-part download, it could cause this situation that triggered this bug.
I'm interested in what kind of application depends on this behavior - if an application gets partial data from the server, especially one that doesn't match the content-length header, that should always be an error to me.