Curl does not currently lower case HTTP header names as required by HTTP/2 and HTTP/3. The lower-level libraries that curl uses (nghttp for HTTP/2 and ngtcp2/quiche for HTTP/3) do lower case the header names, but it does mean for some of the output, before the lower library is invoked, curl can show upper case header names which could be confusing.
While this may seem somewhat pedantic, I still see some developers who are caught by surprised by this more strict requirement for HTTP/2 and HTTP/3 so would prefer curl to not display this as it does currently.
As I see it, we can do one of three things here:
Ignore it. It's just a display issue and at the end of the day curl behaves correctly when it goes to actually send the message. Lowercasing the header names may have a slight performance cost and it will be done anyway in lower level library so pointless doing it twice. We have bigger fish to fry so let's close this issue.
Correct this when printing the output for HTTP/2 and HTTP/3, which is relatively low risk as not really changing anything except the output.
Correct the actual header name when using HTTP/2 or HTTP/3, which does alter the actual header name, so may be higher risk than 2, but which the lower level library should be doing anyway so maybe not that much of a risk.
A fact, incidentally, that caused me some confusion when I initially tried to test the HTTP/2 part of this change, as didn't realise I had to explicitly turn on DEBUG_HTTP2 in the code to see similar output for h2 :-)
Anyway, because I went with my option 3, this change also changes the non-debug lines below this (except for the Host: hostname line which is a dummy HTTP/1.1-style line which is created by curl):