HTTP::Error raised on text/plain response hides raw Expo response

[donni106]

We are using expo-server-sdk 0.1.6 together with http 5.3.1 in a Rails / Sidekiq production setup.

We hit an intermittent failure while sending push notifications:

HTTP::Error: Unknown MIME type: text/plain

Did you ever see this before?

The exception appears to come from the response parsing path inside the gem, specifically where response.parse is called in lib/push/client.rb.

From what we can see, the problem is not necessarily the push request itself, but the response parsing step:

• the notification may already have been accepted by Expo
• but if the upstream response has Content-Type: text/plain, the http gem raises before the raw response can be inspected
• as a result, applications cannot see the actual response status, headers, or body

This makes production debugging difficult, especially for transient upstream/proxy/CDN issues.

Expected behavior:

• either handle unexpected content types more gracefully
• or raise a gem-specific error that includes access to the raw HTTP response
• or allow callers to inspect status, headers, and body before JSON parsing happens

Suggested improvement:

• rescue HTTP::Error around response.parse
• include response metadata in the raised error if possible
• optionally fall back to reading response.to_s and raising a more descriptive Expo::Push::ServerError

A minimal improvement would already be very helpful:

• expose the response status
• expose the Content-Type
• expose the raw body snippet

That would let applications distinguish between:

• actual Expo API errors
• transient proxy/CDN/network issues
• malformed or unexpected upstream responses

I would be very happy to collaborate on this, and I am available for any follow-up questions at any time and can respond quickly on short notice.

[SleeplessByte]

I have not seen this yet, but Expo isn't known for "non-breaking changes", so this does not suprise me at all.

@donni106 thank you for your detailed report. I think I would like the following:

• Detect if content type (partition by ; to filter parameters) starts with application/json or ends with +json. If so, continue to parse.
• If not, and the content type is missing or text/plain, see if it starts with [ or {, and still try to parse (assume Expo made a mistake).
• When parsing fails, raise Expo::Push::ServerError (cause: Expo::Push::ParseError)
• Add response.to_s to ServerError as a field

That said, things I would be okay with without prejudice:

• rescue HTTP::Error around response.parse
• include response metadata in the raised error if possible
• optionally fall back to reading response.to_s and raising a more descriptive Expo::Push::ServerError
• expose the response status
• expose the Content-Type
• expose the raw body snippet

The reason I did not want to expose all the response headers is because in some implementations of Ruby, irc, you MUST consume or throw out the body or whatever it was to ensure no leaking. I don't know or remember if this was also the case with the built-in lib, but since that I kinda just always default to this stuff not being the raw response. Hope that makes sense.

When possible, I still like to not expose the raw response, but alas. I would be okay with it in a block!

I am currently extremely time-constrained, but if you or @pwilimzig want to work on this, please please do. Ping me profusely if I do not respond or review. Once reviewed, I am happy to mint a new gem and push it up to rubygems/coop.