fix(utils): accept HeadersInit, null, undefined in buildOutgoingHttpHeaders

[usualoma]

I understand that res.headers is not necessarily an instance of Headers when 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 not Headers. The reason is as follows

• The header name is case-insensitive, so you cannot compare it directly using an Object key, such as === 'set-cookie'
• The value “ should be preserved without being deleted

[usualoma]

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.
6a6be4f

In Node, if an application passes a value like undefined to the constructor of Headers, the following result will be obtained.

> new Headers({"a":undefined})
Headers { a: 'undefined' }

Does it actually happen that NestJS specifies undefined as the value for “headers that should not be sent”?

[mjad218]

@usualoma Sounds good. new Headers(object) will map objects to headers instance. So, I think your solution is good.

and new Headers(null or undefined) works and does not throw errors.

[usualoma]

@mjad218 Thanks for the reply!

@yusukebe How about this approach?

[yusukebe]

LGTM!

[yusukebe]

Thanks @usualoma !

This is simple, and it can handle the problems. Looks good!