-
Notifications
You must be signed in to change notification settings - Fork 551
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
Normalize headers in interceptors #3860
Comments
It is true that interceptors are making wrong assumptions of the headers, and happy to receive PR for helping fixing them. But I doubt will be easy to normalize them as we allow callers to use I'd prefer fixing them accordingly in sync with the contract we set for |
cc @ronag |
on my list |
Do you have something in mind for this @ronag? |
@metcoder95 the new hook api always passes along normalized headers #3878 |
Ah, this is for the request part. Tricky... the compose API doesn't quite support this use case. |
This would solve...
Some interceptors assume the request headers are necessarily objects:
undici/lib/interceptor/cache.js
Lines 238 to 242 in 6551919
undici/lib/interceptor/dns.js
Lines 360 to 363 in 6551919
undici/lib/handler/redirect-handler.js
Lines 231 to 236 in 6551919
The implementation should look like...
IMHO, the interceptors should convert the request headers to an object before using them, considering that it makes them easy to manipulate and most users will provide them already as objects, so no conversion is needed.
I have also considered...
An alternative could be to fix the interceptors to handle the headers based on the possible types, but this would make very difficult to implement some logics, like checking the value of some headers (which is needed in the cache interceptor)
Additional context
Using redirect and dns interceptors:
The text was updated successfully, but these errors were encountered: