Rescue JSON parse failures and return raw bodies instead? about http

[ixti]

Although I clash the same idiotic behavior of 3rd-parties myself, I don't think it's a responsibility of HTTP gem to handle such situations. At the moment HTTP gem will raise Unknown mime type error in case it does not know how to parse response. I prefer to handle this situation on app-level, e.g.:

def some_call
  res = HTTP.accept(:json).get "..."
  fail res.to_s unless 200 == res.status
  res.parse
end

Or you can handle parse errors like:

begin
  res = HTTP.get "..."
  res.parse
rescue => e
  fail  "Unexpected response (#{e}): #{res}"
end

Or even explicitly say what type of content you want to parse:

begin
  res = HTTP.get "..."
  res.parse :json
rescue => e
  fail "Unexpected response (#{e}): #{res}"
end

[tarcieri]

Yeah, seems like you should just be able to call #to_s in the event #parse raises an exception, no?

[indirect]

Huh. I'm having trouble reproducing now, but iirc the post() raised an exception, so there was no response for me to call to_s on. I'll try to reduce the failure case.

On Mon, Apr 21, 2014 at 10:46 AM, Tony Arcieri [email protected]
wrote:

Yeah, seems like you should just be able to call #to_s in the event #parse raises an exception, no?

Reply to this email directly or view it on GitHub:
#126 (comment)

[tarcieri]

This was on 0.6?

On Monday, April 21, 2014, André Arko [email protected] wrote:

Huh. I'm having trouble reproducing now, but iirc the post() raised an
exception, so there was no response for me to call to_s on. I'll try to
reduce the failure case.

On Mon, Apr 21, 2014 at 10:46 AM, Tony Arcieri <[email protected]javascript:_e(%7B%7D,'cvml','[email protected]');>

wrote:

Yeah, seems like you should just be able to call #to_s in the event

#parse raises an exception, no?

Reply to this email directly or view it on GitHub:
#126 (comment)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/126#issuecomment-40963649
.

Tony Arcieri

[ixti]

@indirect is this issue still active? :D

[ixti]

I take it as no. Please let me know if you still have any issues.

[javierjulio]

The issue I see here is by using say a Ruby library that uses HTTP internally, I don't believe there is a way to get at the response in case of a MimeType error since the decode method just raises an HTTP::Error with a message but nothing else. Common case would be working with a JSON API that at exceptional times returns an HTML response (e.g. most likely due to a 5xx error). The thing is reviewing the code its just an error object with the message, no response data. Is there anyway to get the response itself from the error object?

[tarcieri]

If you really want this behavior, why not consume the body yourself and call JSON.parse?

I don't think it makes sense to silently downgrade to a raw body on a parse error.

[zanker]

Agreed with @tarcieri. If you're working with a server that misbehaves and returns a content type that mismatches, I think it's better to be explicit and parse it yourself then.

[javierjulio]

I wasn't suggesting a change but merely if possible to get the response in case of an error. If not, then thats ok. I'm fortunate since I'm not just the library consumer but author as well haha. The thing is my app isn't making the request, but rather through a library that is using HTTP. I realize now I should be very careful with response mime type and handle appropriately despite it being a JSON API that I'm working with. Yes the third party service I'm using does misbehave in this case. I'll be more mindful going forward. Thanks for the replies!

[ixti]

If 3rd party service misbehaves, you can write a small helper inside your library (I do that way myself. Something like this:

class MyCoolSomething
  class Error < StandardError; end

  def initialize
    @client = HTTP.auth(ENV["API_KEY"])
  end

  def users
    request(:get, "/users").fetch("users")
  end

  private

  def request(verb, endpoint, *args)
    res = @client.request(verb, "http://example.com#{endpoint}", *args)
    raise Error, "Request did not succeed: #{res.status}" unless res.status.ok?

    begin
       res.parse
    rescue => e
      raise Error, "Can't process response: #{e}"
    end
  ensure
    @client.close
  end
end

[britishtea]

What I think @javierjulio means is: is there something like a HTTP::Error#request?

This could be handy when dealing with 3rd party libraries (such as API wrappers) that are not properly handling errors. The better solution is of course to patch the library to properly handle errors.

[ixti]

@britishtea No, there's no such thing at the moment, and I can't see really good way to introduce it. Parse error happens not from the response actually. #parse is nothing more but a syntax sugar for:

HTTP::MimeType[response.mime_type]
  .decode(response.to_s)

In other words neither picking up correct mime type handler, nor decoding is actually belongs to Response in any way. At least in my opinion :D On the other hand, @httprb/core what do you guys think about adding re-raise block to #parse:

module HTTP
  class Response
    class ParseError < ResponseError
      attr_reader :response

      def initialize(response)
        @response = response
        super()
      end
    end

    def parse(...)
      # ...
    rescue
      raise ParseError, self
    end
  end
end