I agree that adding the space seems more consistent....  But in H2/QUIC, I'm not sure we allow trailing/leading spaces, since they should be ignored in HTTP.  I have no idea if that's required behavior per the corresponding specs or not.

I can also reproduce with fetch:

fetch('/fgftgrft', { mode: 'same-origin', headers: { x: 'x', 'X': '' } });

So I don't think it's happening in the XHR code.

I'm a lil busy this week, but it somewhat makes sense to me to have everyone change to Chrome's behavior here, if H2 and QUIC guarantee no trailing space.

That would give a consistent HTTP semantic across versions and also give a consistent story to service workers. So maybe we should make Fetch strip trailing spaces before doing a request, unless there's an easier fix.

So would that be never a space after an added comma "Foo: ,bar,,", or only at the end ("Foo: , bar, ,")?  Regardless, looking at the H2 spec, I can find no mention of restrictions on what can or cannot appear in the header value field (It's possible I'm missing something.  It's also possible it just defers to HTTP/1.x).

I was thinking only at the end, hence deferring the trimming to early on in the fetch (which also means the space would be visible in the Headers object where you created it). It's not exactly great, but it's also the only way to get a trailing space which maybe isn't warranted...

Sorry, I overlooked #2...

external/wpt/xhr/setrequestheader-combining.window.js is the test for this issue.