fix: correctly handle multi-value headers in fetch when rawHeaders contains array

[hexchain]

This relates to...

#4389

Changes

In httpNetworkFetch->dispatch->onHeaders, append multi-value header values one by one and let HeadersList handle concatenation.

Features

N/A

Bug Fixes

#4389

Breaking Changes and Deprecations

N/A

Status

• I have read and agreed to the Developer's Certificate of Origin
• Tested
• Benchmarked (optional)
• Documented
• Review ready
• In review
• Merge ready

[hexchain]

I've pushed a different fix as discussed in #4390 (comment). Please take a look, thanks!

[metcoder95]

code wise, lgtm; but defer to @KhafraDev

[metcoder95]

As this only breaks given an interceptor, I'd prefer that we fix it within undici's rather than fetch

[hexchain]

My idea is that fetch should properly support arrays of header values in rawHeaders, if such case is valid.

[metcoder95]

Sure, but I'd prefer to cross check with the spec to see what it has to say regarding duplicated headers, if the implementation already aligns, most likely is an undici issue.

[hexchain]

IIUC, RFC 7230 Section 3.2.2 means that:

• A sender must not send multiple headers with the same name unless it is Set-Cookie,
• A receiver may combine values of multiple headers with the same name into a comma-separated list, except for Set-Cookie.

I'd say it is fine to have them separated in Undici/interceptor APIs, and only join them in fetch.

[Uzlopak]

You refer to RFC7230 but not the fetch spec

[hexchain]

Gentle ping. May I have some reviews again?

The latest change only touches fetch and not (Un)wrapHandlers, so no changes to existing interceptor/handler behaviors. Duplicate headers are processed mostly in the same way as before, except when interceptors exist, in which case it is more correct than before - it uses HeadersList.append now instead of Array<Buffer>.toString.