use lowercase header keys while making requests

[lohxt1]

#3723

https://datatracker.ietf.org/doc/html/rfc7230#section-3.2

workaround for the above issue:
use content-type instead of Content-Type

[ramki-bruno]

Just checked the behavior of curl w.r.t. this and it doesn't seem to modify header-keys.
Which actually makes sense, even though the standard states that its supposed to be case-insensitive, we don't have to make sure of it.
IMO, its better to let it be up to the user and the server implementation.

Check the end of the lines above <= Recv header..

$ curl --trace - http://localhost:4000 -H "X-Foo: bar" -H "x-foo: Bar"
== Info:   Trying 127.0.0.1:4000...
== Info: Connected to localhost (127.0.0.1) port 4000 (#0)
=> Send header, 101 bytes (0x65)
0000: 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 0d 0a GET / HTTP/1.1..
0010: 48 6f 73 74 3a 20 6c 6f 63 61 6c 68 6f 73 74 3a Host: localhost:
0020: 34 30 30 30 0d 0a 55 73 65 72 2d 41 67 65 6e 74 4000..User-Agent
0030: 3a 20 63 75 72 6c 2f 38 2e 31 2e 32 0d 0a 41 63 : curl/8.1.2..Ac
0040: 63 65 70 74 3a 20 2a 2f 2a 0d 0a 58 2d 46 6f 6f cept: */*..X-Foo
0050: 3a 20 62 61 72 0d 0a 78 2d 66 6f 6f 3a 20 42 61 : bar..x-foo: Ba
0060: 72 0d 0a 0d 0a                                  r....
<= Recv header, 17 bytes (0x11)
0000: 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0d HTTP/1.1 200 OK.
0010: 0a                                              .
<= Recv header, 25 bytes (0x19)
0000: 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 Content-Type: te
0010: 78 74 2f 68 74 6d 6c 0d 0a                      xt/html..
<= Recv header, 37 bytes (0x25)
0000: 44 61 74 65 3a 20 46 72 69 2c 20 31 37 20 4a 61 Date: Fri, 17 Ja
0010: 6e 20 32 30 32 35 20 30 38 3a 34 39 3a 35 33 20 n 2025 08:49:53
0020: 47 4d 54 0d 0a                                  GMT..
<= Recv header, 24 bytes (0x18)
0000: 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 6b 65 65 70 Connection: keep
0010: 2d 61 6c 69 76 65 0d 0a                         -alive..
<= Recv header, 23 bytes (0x17)
0000: 4b 65 65 70 2d 41 6c 69 76 65 3a 20 74 69 6d 65 Keep-Alive: time
0010: 6f 75 74 3d 35 0d 0a                            out=5..
<= Recv header, 28 bytes (0x1c)
0000: 54 72 61 6e 73 66 65 72 2d 45 6e 63 6f 64 69 6e Transfer-Encodin
0010: 67 3a 20 63 68 75 6e 6b 65 64 0d 0a             g: chunked..
<= Recv header, 2 bytes (0x2)
0000: 0d 0a                                           ..
<= Recv data, 19 bytes (0x13)
0000: 39 0d 0a 68 65 6c 6c 6f 2e 2e 2e 0a 0d 0a 30 0d 9..hello......0.
0010: 0a 0d 0a                                        ...
hello...
== Info: Connection #0 to host localhost left intact

[ramki-bruno]

use content-type instead of Content-Type

@lohxt1 More details on how this is solving the issue would be helpful.

[bbak]

Interestingly, according to RFC9110 Section 5.1 (obsoletes RFC7230) these so-called field names are "case-insensitive". The HTTP Field Name Registry, in turn, capitalizes the first character of every word and at times the whole field name.

By digging through the Axios sources, it seems like they lowercase any field name in normalizeHeader() internally while capitalizing the first character when constructing the HTTP message to send, so they look like in the HTTP Field Name Registry (see: formatHeader()).

From that perspective, it shouldn't make any difference. Yet most likely this is not the whole story.

The npm:form-data package seems to use lowercase headers, though (see: FormData.prototype.getHeaders()).