http_status() should expose more content

[jennybc]

http_status() is used when we turn a response into a warning or error. But it fails to reveal everything contained in the response about what went wrong.

Recent example encountered in gargle: r-lib/gargle#111

The problem ended up being that auth was initiated from a Docker container whose system time was 2 days out of sync! And this error was actually detailed in a response during the failure to get an access token via init_oauth_service_account(). Using debug() to inspect the response revealed this explanation:

content(res, "text")
# "{\n  \"error\": \"invalid_grant\",\n  \"error_description\": \"Invalid JWT: Token must be a short-lived token (60 minutes) and in a reasonable timeframe. Check your iat and exp values and use a clock with skew to account for clock differences between systems.\"\n}"

but these details are not being surfaced by http_condition() and, therefore, stop_for_status().

[rbrown789]

Another example of this. I've been using httr to access the Auth0 Management API in a shiny app. Whenever an API call returns an error, the error details are contained in the "message" field of the JSON response (example for creating a user with a username that's too long):

content(resp,"text") 
# "{\"statusCode\":400,\"error\":\"Bad Request\",\"message\":\"Username should have between 1 and 15 characters.\",\"errorCode\":\"auth0_idp_error\"}"

But http_status() only returns the following:

http_status(resp)
# $category
# [1] "Client error"
# 
# $reason
# [1] "Bad Request"
# 
# $message
# [1] "Client error: (400) Bad Request"

[hadley]

httr has been superseded in favour of httr2, so is no longer under active development. If this problem is still important to you in httr2, I'd suggest filing an issue offer there 😄. Thanks for using httr!