If the URL contains an ampersand (&) it is interpreted as "run in a different process" in the command line shell.
Wrapping it in quotes might be helpful.

When several form parameters are provided, the output from h2c is garbled.

This curl command:
curl --form ONE=1 --form TWO=2 --form THREE=3 http://localhost:8000

Performs this request:

POST / HTTP/1.1
Host: localhost:8000
User-Agent: curl/7.47.0
Accept: */*
Content-Length: 327
Expect: 100-continue
Content-Type: multipart/form-data; boundary=------------------------48e1b0f105811e87

--------------------------48e1b0f105811e87
Content-Disposition: form-data; name="ONE"

1
--------------------------48e1b0f105811e87
Content-Disposition: form-data; name="TWO"

2
--------------------------48e1b0f105811e87
Content-Disposition: form-data; name="THREE"

3
--------------------------48e1b0f105811e87--

Which h2c outputs as:

curl --http1.1 --user-agent "curl/7.47.0" --form ONE=1 --form TWO=1
2 --form THREE=1
2
3 https://localhost:8000/

Note that the value of the form fields keeps accumulating instead of resetting. TWO's value is 1\n2 and THREE's value is 1\n2\n3.

When a mutlipart form value contains spaces, h2c outputs --form FOO=1 2 3 4 instead of --form 'FOO=1 2 3 4'.

Since h2c's output is a valid shell command, one should be careful with other characters such as ; or ', which may require quoting or escaping.

h2c -h shows no output, no error.

The following input

POST /ws/ HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Content-Type: application/soap+xml
User-Agent: WSDAPI
Content-Length: 645
Host: 10.61.64.55

<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"><soap:Header><wsa:To>urn:uuid:3ba66c80-1dd2-11b2-8f68-9c934e243796</wsa:To><wsa:Action>http://schemas.xmlsoap.org/ws/2004/09/transfer/Get</wsa:Action><wsa:MessageID>urn:uuid:c949ad8f-925c-4ec0-b110-9484bbbda578</wsa:MessageID><wsa:ReplyTo><wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address></wsa:ReplyTo><wsa:From><wsa:Address>urn:uuid:b2dbd154-99d4-46e4-b4d8-603df5363b18</wsa:Address></wsa:From></soap:Header><soap:Body/></soap:Envelope>

produces

curl --header Accept: --header "Content-Type: application/soap+xml" --header "Cache-Control: no-cache" --header "Connection: Keep-Alive" --header "Pragma: no-cache" --user-agent "WSDAPI" --data-binary "urn:uuid:3ba66c80-1dd2-11b2-8f68-9c934e243796http://schemas.xmlsoap.org/ws/2004/09/transfer/Geturn:uuid:c949ad8f-925c-4ec0-b110-9484bbbda578http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymousurn:uuid:b2dbd154-99d4-46e4-b4d8-603df5363b18" https://10.61.64.55/ws/

But the string after --data-binary is only a part of the real body.

Command is not readable on Safari with dark mode. We can add a color property to the line below:
https://github.com/curl/h2c/blob/master/h2c.html#L25

Similar to the -F multipart bugs, the strings after --data-bianry are not escaped.

Given this input:

POST / HTTP/1.1
Host: localhost:8000
User-Agent: curl/7.47.0
Accept: */*
Content-Length: 5
Content-Type: application/x-www-form-urlencoded

$PATH

h2c outputs:
curl --http1.1 --user-agent "curl/7.47.0" --data-binary "$PATH" https://localhost:8000/

A POSIX shell will expand $PATH.

GET http://example.com/this HTTP/1.1
Host: example.com
User-Agent: moo/2000

We don't know where the proxy is so we can't generate a perfect command line, but we can do better than now...

$ ./h2c < test-proxy
curl --http1.1 --header Accept: --user-agent "moo/2000" https://example.comhttp://example.com/this

I think h2c is a useful and cool tool and would like to included it as an official Homebrew package, so that people on macOS can install it with a single command brew install h2c.

However, h2c does not have any tagged releases, and is not acceptable in Homebrew/core per homebrew policy.

Can you consider publishing the latest (stable) commit to GitHub release? Thanks!

With the new --libcurl option, h2c can now generate libcurl code. The online version should then pipe that through enscript and generate a syntax-highlighted version of the code, and preferably with links on function and option names much like the examples do.

... which should make curl use --compressed, even if that might not be a 100% match.

Current behaviour:
Seems that any input generates "https" output

Desired:
User may indicate which scheme they want in the generated URL: http/https.