Adds HTTP/1.1 support on cleos requests and improves response handling

[leordev]

Change Description

• Upgrades cleos http 1.0 to 1.1: in more advanced cloud stacks cleos is being rejected by gateways or proxies with HTTP status 426:

The HTTP 426 Upgrade Required client error response code indicates that the server refuses to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol. The server sends an Upgrade header with this response to indicate the required protocol(s).

• Removes unnecessary json parsing if it's an error code
• Straight dump responses for --print-response if unable to convert to variant

Change Type

• Documentation
• Stability bug fix
• Other
• Other - special case

Consensus Changes

• Consensus Changes

API Changes

• API Changes

Documentation Additions

• Documentation Additions

[heifner]

Why remove the pretty print of the response? The point is to make this human readable. Do you need to parse this?

[b1bart]

I agree, this does remove the forced pretty-printing of the json and instead relies on the service endpoints choice of formatting which may be very efficient and less readable as a result.

[leordev]

The reason was because we don't know if it was a successful response so far and we might just dump the response if it's a useful plain text error...
For example, for the PR root problem the status code 426 does not give any json... I imagine there are other handful errors that could either not be a json and have a plain text or have no response at all.

Do you think we should do some checks and prettify if it's a valid json?

[heifner]

I believe that fc::json::to_pretty_string will print invalid json just fine. Did you find something where information was lost?

[arhag]

The issue was the call to fc::json::from_string can throw an exception and prevent the response from being printed out.

One option is to still try the from_string anyway, catch any exception, and in the case of exception print a non-pretty response, otherwise it can make response_result pretty and print that.

[heifner]

@leordev Can you update this PR as @arhag suggests.

[heifner]

@leordev I went ahead and made @arhag suggested changes. @arhag can you review now please.

[leordev]

oh thank you @heifner 💯💯💯 -- I was going to go back here and do that as soon as I have a chance but I got stuck in other high priority items!

[arhag]

@heifner Change looks fine to me.

[arhag]

@heifner

Hmm. Actually, under some status codes, this now could either return a null variant or it would throw an alternative exception as it tries to convert the null variant to some other type.

Do we want to rethrow the original exception after printing the response if it is null?