Closed scottbale closed 1 year ago
I want to point out that the http server can ultimately decide what encoding to use when creating a respose. In general it's advised to consider at least the "content-type" of every response to determine how to interpret the http body. (See https://www.rfc-editor.org/rfc/rfc7231#section-3.4.1)
I want to point out that the http server can ultimately decide what encoding to use when creating a respose. In general it's advised to consider at least the "content-type" of every response to determine how to interpret the http body. (See https://www.rfc-editor.org/rfc/rfc7231#section-3.4.1)
@phmeier-nubank in this case, we send "accept" "application/json" and don't get back any "content-type" header.
This issue was uncovered while reproducing #174.
Dependencies
I was able to reproduce #174 both with the dependencies listed there and the following:
Description with failing test case
Here is a simplification of the #174 steps to reproduce:
Stack traces
Here is an abbreviated stack trace, see #174 for full stack trace.
Note the
JSON error (unexpected character): <"
. The response from AWS is a 404, the body is the string<UnknownOperationException/>
which, being XML instead of the expected/requested JSON, causes thejson-parse-error
function to throw an uncaught exception.In other words, although this operation is expected to fail because of the lack of
:endpoint-override
, the response body is unexpectedly formatted as XML instead of JSON.This issue is for potentially making the error response parsing more robust in the face of behavior like this.