-
-
Notifications
You must be signed in to change notification settings - Fork 130
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
feat(fetch): support following redirect responses #627
Conversation
8955263
to
e9ef8c7
Compare
e9ef8c7
to
9fba26d
Compare
await httpServer.close() | ||
}) | ||
|
||
it('follows a bypassed redirect response', async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added the tests for all scenarios we can reproduce from Undici.
/** | ||
* @see https://github.com/nodejs/undici/blob/a6dac3149c505b58d2e6d068b97f4dc993da55f0/lib/web/fetch/index.js#L1210 | ||
*/ | ||
export async function followFetchRedirect( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation of following redirects.
* This way, the client can manually follow the redirect it receives. | ||
* @see https://github.com/nodejs/undici/blob/a6dac3149c505b58d2e6d068b97f4dc993da55f0/lib/web/fetch/index.js#L1173 | ||
*/ | ||
if (RESPONSE_STATUS_CODES_WITH_REDIRECT.has(response.status)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix: handle redirect responses in a special way.
I'd also look into following redirects in |
Released: v0.35.0 🎉This has been released in v0.35.0! Make sure to always update to the latest version ( Predictable release automation by @ossjs/release. |
Amazing PR! |
Warning
Marking this as a breaking (feat) release because mocked redirect responses will now be followed by default (previously, returned as-is). The previous behavior was faulty and not spec-compliant, but I don't want to break consumers once again.
The redirect response handling is taken from Undici almost as-is because it doesn't export its
web/fetch/utils
as a typed module (it's untyped CJS). Luckily, Undici follows the spec in those implementations so they are unlikely to change. I'm also omitting things that are exclusive to Undici, such as accessingrequest.body.source
.Relevant resources