Commits on Jan 6, 2024

1. Ensure correct Faraday JSON parsing/response body for invalid respons… …

   …e header
   
   See my investigation here:
   #100 (comment)
   
   In the Faraday 1 to Faraday 2 process, the ensure JSON response
   middleware was rewritten from scratch, which caused a change in how
   permissive the middleware was to response Content-Type headers which did
   not properly indicate a JSON response.
   
   In Faraday 1.x, the JSON middleware would attempt a JSON parse of the
   body, regardless of the presence or value of a Content-Type header. This
   meant that Graphlient would have raised an exception (or re-raised one
   caught from Faraday) if the response body was not valid JSON.
   
   In Faraday 2.x, the new JSON middleware will only attempt to parse the
   response body if it determines that the Content-Type response header
   indicates a JSON body. By default it uses a regex on the header value
   (/\bjson$/ at the time of writing). Crucially, if the header is missing,
   or does not match the regex, instead of raising an exception,
   `Faraday::Response#body` returns a String, rather than the
   previously-assumed Hash or Array.
   
   This change restores the parsing logic which is tolerant to incorrect or
   missing Content-Type header values. Response bodies which are not valid
   JSON will raise an exception. Any unforseen situation where `#body`
   returns a type that is not String, Hash, or Array, will raise a separate
   exception detailing that this is unexpected behavior and a bug should be
   filed.
   
   Resolves #100

   

   taylorthurlow committed Jan 6, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for fefb02c
   • Browse repository at this point

   Copy the full SHA

   fefb02c View commit details

   Browse the repository at this point in the history