Closed vicwilliam closed 2 months ago
Love the detailed writeup! Super helpful - should be fixed in 5.0.17
:)
If anyone is still having issues with this in 5.0.17
, I found that I had to bypass corsify
for redirect responses. I'm not quite sure why, but it works now. Here is my code:
const { preflight, corsify } = cors();
type CFArgs = [Env, ExecutionContext];
// Do not corsify for redirections
const wrappedCorsify = (response: Response, request?: Request): Response => {
if (response?.status === 302) {
return response;
}
return corsify(response, request);
};
const router = AutoRouter<IRequest, CFArgs>({
before: [preflight],
finally: [wrappedCorsify]
});
router
.get('/authorize', (request, env) => {
return Response.redirect(
`https://github.com/login/oauth/authorize?client_id=${env.GITHUB_OAUTH_APP_CLIENT_ID}&scope=gist`,
302
);
}
);
Hello, we're having the same issue in Cloudflare for almost every response with itty-router 5.0.17
. Using corsify()
results on a "Can't modify immutable headers."
error every time a header is modified by corsify
.
After investigating, the solution that worked for us was to create a new response in corsify()
: new Response(...)
instead of modifying the cloned response.
Describe the Issue
Cached responses throws error when corsify is in use. Non cached responses work well.
Example Router Code
Request Details
/hello
Steps to Reproduce
Steps to reproduce the behavior:
/hello
, first response is not cachedExpected Behavior
Expected to have a cached response with no errors and cors applied when necessary, same behaviour from router-itty 4 with corsify
Actual Behavior
An error is thrown if the request is cached and the request fails.
Environment (please complete the following information):
Workaround
A workaround. Not calling corsify if the response is cached. To check if it's a cached response, just see if a header not added by you is present in the cached response.