setHeaderOptions should normalize header keys

[simhnna]

Describe the bug
Currently to override any header that's already set by the library you need to match the case. If the case changes for whatever reason the code breaks.
This causes hard to debug issues.

I suggest lowercasing all headers so they correctly override regardless of case used anywhere. HTTP1 defines header keys as case insensitive, HTTP2 requires lowercase headers. https://www.rfc-editor.org/rfc/rfc7540#section-8.1.2

If you don't decide to lowercase header keys right now, setHeaderOptions should at least compare the new keys to existing ones case insensitively and overwrite existing values instead of adding new entries

[mstruebing]

I think converting them to lowercase makes sense especially since HTTP2 requires it.
There will be a couple of places where this needs to be adjusted and probably even in the openapi generator itself.

[brendandburns]

Shouldn't the fetch transport handle this if it negotiates http2?

We should verify that this works correctly in the Go lang API server code.

and then also agree that this is probably a change in the generator.

[abdulfarid-dev]

I understand the issue now. Just to confirm if all headers are converted to lowercase internally it won’t break existing code right?
I agree this change will make header overriding more reliable across HTTP/1 and HTTP/2.

[mstruebing]

@abdulfarid-dev As per spec, it shouldn't break anything, yes.

• HTTP1 headers are case insensitive, so the casing doesn't matter, HeAdEr: abc would be treated the same as header: abc
• HTTP2 requires headers to be lowercase, so only header: abc would be allowed.

What happened until now is that we set different casing as different headers as it seems.
So we would have set HeAdEr as well as header in the end just one of them "wins" which is hard to debug and figure out.