Specify json content type in RPC examples.
Picks up #29946. Which needed rebasing and the commit message fixing,
Specify json content type in RPC examples
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--006a51241073e994b41acfe9ec718e94-->
For detailed information about the code coverage, see the test coverage report.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
ACK for 3c08e11c3ea4499e8d20609e2417cac859b3e98e
This is a reasonable change, which over time can help nudge implementations to usage of the more appropriate content-type application/json.
I didn't see mention of content-type or linked RFC in the JSON-RPC v1 spec (https://www.jsonrpc.org/specification_v1), but the JSON-RPC 2.0 spec does reference RFC 4627 (https://www.ietf.org/rfc/rfc4627.txt), which specifies (in section 6) the type/subtype of application/json. RFC 4627 is obsoleted by 7159, which in turn is obsoleted by 8259, but the result is the same (section 12 of 8259 specifies usage of application/json).
nit: Technically, I think the trailing semicolon application/json; may be unnecessary, since there are no parameters specified with the content-type. https://www.rfc-editor.org/rfc/rfc2616#section-14.17, https://www.rfc-editor.org/rfc/rfc2616#section-3.7
Content-Type = "Content-Type" ":" media-type
media-type = type "/" subtype *( ";" parameter )
While JSON-RPC 2.0 support was recently added (with backwards compatibility for pre-2.0) and the examples continue to specify "jsonrpc": "1.0", I think it's appropriate that this PR is scoped to updating just the content-type. Updating examples to use "jsonrpc": "2.0" would be best left to a later PR.
Sanity checking performed: viewed JSON-RPC-interface.md rendered in-browser, built and ran unit and functional tests (all passed, including rpc_tests), ran bitcoin-cli without the trailing semicolon to see how bitcoind would handle it (successful).
ACK 3c08e11c3ea4499e8d20609e2417cac859b3e98e This is an obvious documentation improvement.
nit: Technically, I think the trailing semicolon application/json;
Good catch. Content type doesn't need to be suffixed with ;. It's pretty uncommon, even. According to the curl doc the semicolon is a special syntax for providing an empty header, but not required otherwise, eg the example they give is:
curl -H "X-First-Name: Joe" http://example.com/
Also,
JSON text SHALL be encoded in Unicode. The default encoding is UTF-8.
So it's never necessary to provide say Content-type: application/json; charset=utf-8.
29947