Curl does not lowercase header names for HTTP/2 and HTTP/3

[tunetheweb]

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.

For example:

As I see it, we can do one of three things here:

1. 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.
2. 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.
3. 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.

I've taken a stab at option 3 here: master...bazzadp:lowercase_h2_h3_headernames.

I'd appreciate your thoughts on this and if it's worth submitting this as a pull request?

It's my first potential commit to curl, and my C is a little rusty, so please be kind :-)

[bagder]

Thanks @bazzadp! I think it looks perfectly reasonable so please make a PR out of it!

[jay]

putting aside the lowercase question why are the headers prefixed h3 like h3 [key: val] and not just key: val

[bagder]

That h3 output is debug-only output that a normal build won't show:

curl/lib/vquic/quiche.c

Lines 697 to 699 in 41db01a

	H3BUGF(infof(data, "h3 [%.*s: %.*s]\n",
	nva[i].name_len, nva[i].name,
	nva[i].value_len, nva[i].value));

I would imagine we can remove that at some point as it doesn't really add much.

[tunetheweb]

It's the same with h2 [key: val], the only difference being at the moment h2 is turned off by default, where as h3 DEBUG_HTTP3 is currently turned on for Quiche:

curl/lib/vquic/quiche.c

Lines 43 to 46 in 41db01a

	#define DEBUG_HTTP3
	/* #define DEBUG_QUICHE */
	#ifdef DEBUG_HTTP3
	#define H3BUGF(x) x

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):

> HEAD / HTTP/2
> Host: www.tunetheweb.com
> user-agent: curl/7.67.0-dev
> accept: */*

as opposed to:

> HEAD / HTTP/2
> Host: www.tunetheweb.com
> User-Agent: curl/7.67.0-dev
> Accept: */*

So there is still value in this change, even when not in debug mode, and even when h3 changes to act more like h2.

[bagder]

We should probably at least make the DEBUG_HTTP3 like this, if not disabled completely by default:

#ifdef CURLDEBUG
#define DEBUG_HTTP3
#endif

The HTTP/2 debug is completely disabled by default pretty much because it generates so much data that is mostly uninteresting for everyone as long as you don't actually debug HTTP/2 related issues.