Invalid HTTP method with whitespace in -X / --request ends up in HTTP/2 path

[Omdahake]

I did this

#Problem

When passing a custom HTTP method with spaces using -X or --request, curl sends unexpected pseudo-headers in HTTP/2:

Example:

./curl -X "GET 123" https://example.com -v

Observed HTTP/2 request:

:method: GET
:path: 123 /
:scheme: https
:authority: example.com

The extra tokens after the first word in the method end up in the path, which is non-standard and can confuse servers.

Steps to reproduce

1. Build curl (latest master or release branch).
2. Run: ./curl -v -X "GET 123" https://example.com -v
3. Observe the :path header in HTTP/2.

Observed behavior

• Curl sends :path: 123 / instead of rejecting the invalid method.
• Servers respond with 404 or "Invalid URL".

Expected behavior

• Curl should reject methods containing whitespace according to RFC 9110.
• It should not use leftover tokens as the request path.

Notes

• This is "not a security vulnerability" but a spec compliance issue and could be confusing for users.
• Relevant source file:'tool_getparam.c', in the 'C_REQUEST' case for -X / --request.

I expected the following

• Curl should reject any HTTP method that contains whitespace, instead of sending it.
• No extra tokens after the first word should be used as part of the request path or pseudo-headers.
• The command should return an error message like:

curl/libcurl version

curl 8.18.0

operating system

Operating System: Linux x86_64, Debian 6.1.76-1, Kernel 6.1.0-18-amd64 (SMP PREEMPT_DYNAMIC)

[bagder]

Curl should reject methods containing whitespace according to RFC 9110.

I don't think so. curl has always accepted whatever junk you tell it to use there. You can test your servers by sending fun things the server doesn't expect.

It still shouldn't put parts of the given method in the path field though.

[ruidosujeira]

Good evening everyone... @Omdahake and @bagder,

I was able to reproduce this on current master.

bash
$ ./src/curl -v -X "GET 123" https://example.com --http2
# commit: 517a12922e8a02caf94b70877bf65328a842b87f

The request is sent as:

Text
[HTTP/2] [1] [:method: GET]
[HTTP/2] [1] [:path: 123 /]
...
> GET 123 / HTTP/2

And the server responds with:

Text
< HTTP/2 400
< ...
< TITLE>Invalid URL</TITLE>
...
The requested URL "http://example.com123 /", is invalid.

I’d like to work on a fix that:

• validates the -X/--request method in tool_getparam.c (case C_REQUEST), and

• rejects methods containing any whitespace (per RFC 9110), returning a parameter error instead of sending the request.

Let me know if you’d prefer a stricter validation (e.g. full “token” syntax check) or if rejecting on whitespace is enough for now.

[icing]

It still shouldn't put parts of the given method in the path field though.

Well, the HTTP/2 implementation (and h3 as well), parse the request line and have no way of knowing if the space belongs to the method or the path. What do you propose? Inspect data.set->str[STRING_CUSTOMREQUEST]?

[icing]

Did a fix and test case in #19563