Is the text/plain header truly required? #18950

I already asked this on https://bitcoin.stackexchange.com/ and was referred here.

The docs say "RPC HTTP requests must include a Content-Type header set to text/plain" (src: https://bitcoin.org/en/developer-reference#remote-procedure-calls-rpcs). Calls to an RPC endpoint without this header succeed. Either way, the true Content-Type in this case is application/json. ~Every version of the docs published so far specifies this requirement.

Is it safe for me to remove it or could it cause unexpected behavior? I can imagine none. I am happy to open a PR removing this requirement from the docs if it's not needed.

https://bitcoin.org/en/developer-reference#remote-procedure-calls-rpcs

The website is managed on https://github.com/bitcoin-dot-org/bitcoin.org or https://github.com/achow101/btcinformation.org

Is this also an issue with Bitcoin Core?

Thanks for your speedy response!

The documentation at both links you provided also states this same header requirement (here and here). I'm just trying to understand if it's actually a requirement, in practice it does not seem to be.

No, there is no strict requirement for JSON-RPC to have Content-Type header set to text/plain. I think application/json is more common, and also more relevant.

FWIW bitcoin core uses application/json everywhere, at least in the server, I couldn't find any code in bitcoin-cli to set that header. In any case the server doesn't enforce any specific content type so it doesn't matter.

Edit: bitcoin-cli doesn't send a Content-Type at all, from strace output:

writev(6, [{iov_base="POST / HTTP/1.1\r\nHost: 127.0.0.1\r\nConnection: close\r\nAuthorization: Basic …\nContent-Length: 46\r\n\r\n", iov_len=198},

It might be best to report the bug upstream to the websites https://github.com/bitcoin-dot-org/bitcoin.org and/or https://github.com/achow101/btcinformation.org

I don't think there's a need to keep this open. Things work, there's no actual issue.

If you have any further questions feel free to ask though.