fix(utils): accept HeadersInit, null, undefined in buildOutgoingHttpHeaders #212
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
Author
|
Hi @mjad218, I'd like to hear your opinion. I would like to summarize this matter with this code. However, the following changes you have made will not be reflected in this code. In Node, if an application passes a value like undefined to the constructor of Headers, the following result will be obtained. Does it actually happen that NestJS specifies undefined as the value for “headers that should not be sent”? |
|
@usualoma Sounds good. and |
Member
Author
|
@mjad218 Thanks for the reply! @yusukebe How about this approach? |
Member
|
Thanks @usualoma ! This is simple, and it can handle the problems. Looks good! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I understand that
res.headersis not necessarily an instance ofHeaderswhen combined with another framework. In this kind of environment, I think it is safe to assume that it will return either HeadersInit, null, or undefined.I think it would be better to keep the code from v1.13.3 as it is for processing the contents of the header, and to call
new Headers()if it is notHeaders. The reason is as follows=== 'set-cookie'