Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

USE_HYPER and CURLE_BAD_FUNCTION_ARGUMENT #8894

Closed
gvanem opened this issue May 21, 2022 · 12 comments
Closed

USE_HYPER and CURLE_BAD_FUNCTION_ARGUMENT #8894

gvanem opened this issue May 21, 2022 · 12 comments
Labels

Comments

@gvanem
Copy link
Contributor

gvanem commented May 21, 2022

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
Copy link
Contributor

dfandrich commented May 21, 2022 via email

@bagder bagder added the Hyper label May 21, 2022
@bagder
Copy link
Member

bagder commented May 23, 2022

So which option causes it to say this?

@gvanem
Copy link
Contributor Author

gvanem commented May 23, 2022

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
Copy link
Member

bagder commented May 23, 2022

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

@gvanem
Copy link
Contributor Author

gvanem commented May 25, 2022

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

@bagder
Copy link
Member

bagder commented May 25, 2022

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

@gvanem
Copy link
Contributor Author

gvanem commented May 25, 2022

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
Copy link
Member

bagder commented May 25, 2022

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
Copy link
Member

bagder commented May 25, 2022

Reproduced, PR pending.

bagder added a commit that referenced this issue May 25, 2022
To make sure the headers API can filter it out as not a regular header.

Reported-by: Gisle Vanem
Fixes #8894
@gvanem
Copy link
Contributor Author

gvanem commented May 25, 2022

With that PR, it works.

@gvanem
Copy link
Contributor Author

gvanem commented May 25, 2022

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
Copy link
Member

bagder commented May 25, 2022

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

bagder added a commit that referenced this issue May 25, 2022
To make sure the headers API can filter it out as not a regular header.

Reported-by: Gisle Vanem
Fixes #8894
@bagder bagder closed this as completed in b67dcc8 May 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging a pull request may close this issue.

3 participants