USE_HYPER and CURLE_BAD_FUNCTION_ARGUMENT

[gvanem]

Building libcurl with -DUSE_HYPER always causes the annoying error:
curl: (43) A libcurl function was given a bad argument on any address.
I'm building with the most up-to date version of Hyper.dll.lib on Win-10.

Now, a simple curl.exe -vL4 www.curl.se, just gives this:

...
* STATE: DO => DID handle 0x10011228; line 2145 (connection #0)
* STATE: DID => PERFORMING handle 0x10011228; line 2264 (connection #0)
* HTTP 1.1 or later with persistent connection
< HTTP/1.1 301 Moved Permanently
* multi_done: status: 43 prem: 1 done: 0
* Curl_quic_done
* The cache now contains 0 members
* Closing connection 0
* Expire cleared (transfer 0x10011228)
curl: (43) A libcurl function was given a bad argument

So it would be nice if in verbose-mode (-v) libcurl could state at which point that is happening.
Perhaps only with -DCURLDEBUG. I was thinking of adding something like this to memdebug.h:

static int inline curl_dbg_bad_function_argument (int verbose, const char *file, unsigned line)
{
  if (verbose)
     fprintf(stderr, "%s(%u): Throwing a 'CURLE_BAD_FUNCTION_ARGUMENT'\n", file, line);
  return (CURLE_BAD_FUNCTION_ARGUMENT);
}

#define curl_dbg_BAD_FUNCTION_ARGUMENT(verb)   curl_dbg_bad_function_argument (verb, __FILE__, __LINE__)
...
#ifndef curl_dbg_BAD_FUNCTION_ARGUMENT
#define curl_dbg_BAD_FUNCTION_ARGUMENT(verb) CURLE_BAD_FUNCTION_ARGUMENT
#endif

And using this every place where a data->set.verbose is present.

[dfandrich]

This way won't eliminate the debugging strings if --disable-verbose is selected.

[bagder]

So which option causes it to say this?

[gvanem]

So which option causes it to say this?

Which CURLOPT_x? No idea. That's why I think a CURLDEBUG should be more helpful.

[bagder]

It doesn't help much, but I don't get any such warning on my hyper builds on Linux.

[gvanem]

I found out one candidate for this was here.
So simply removing -DUSE_HEADERS_API from my build everything works with -DUSE_HYPER.

[bagder]

That's very weird. And I'm just about to bring in the headers API in by default... (#8900)

[gvanem]

Adding more traces to headers.c, I see it bitches on a HTTP/1.1 301 Moved for
a command such as curl -Lo NUL www.vg.no. That figures since there's no : in that 301. But that is not a header is it?

[bagder]

Right, for the headers API code it is not a header and it shouldn't go there for the status line. I'll take a look too.

[bagder]

Reproduced, PR pending.

[gvanem]

With that PR, it works.

[gvanem]

More Hyper problems. I'll just add this here.
A command curl --http3 https://www.cloudflare.com, gives:

curl: (56) Hyper: [1] operation was canceled: connection closed before message completed

Building w/o -DUSE_HYPER the same command works fine. But the .html output says:

Please enable cookies.
Sorry, you have been blocked
You are unable to access www.cloudflare.com

[bagder]

Sure, Hyper support is still experimental and "not there yet". We should probably add "co-exist with HTTP/3" as an issue on https://github.com/curl/curl/wiki/Hyper