Fails to decode gzipped responses from Chargebee

[lilith]

When executing ChargeBee::Subscription.retrieve(subscription_id).subscription.as_json

The following error occurs

       Response not in JSON format. Probably not a ChargeBee response
        "\u001F\x8B\b\u0000\u0000\u0000\u0000\u0000

[lilith]

This appears to be a compatibility issues with rest-client 2.1.0.

Specifying gem 'rest-client','= 2.0.2' in Gemfile is a workaround

[loomchild]

@lilith Sorry for contacting you after 5 years. I am trying to upgrade the rest-client gem and I can no longer reproduce the described issue. Could you share what were the reproduction steps? Was it perhaps happening on a specific version of Ruby?

[cb-alish]

Hi @loomchild, please use the following code to reproduce the issue. Ensure that you are using chargebee-ruby version v2.8.6.

subscription = ChargeBee::Subscription.retrieve("{your-subscription-id}", nil, {
    "Accept-Encoding" => "gzip"
})

[loomchild]

Thanks. After adding Accept-Encoding header, I can see the error.

I have two remarks, though:

1. Manually adding Accept-Encoding: gzip header to a request shouldn't be necessary because Net::Http automatically adds Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3 header and decompresses the response if you don't specify Accept-Encoding at all. However, in this case, despite gzip encoding having the highest weight, ChargeBee API won't compress the response, which seems odd (tested using http_logger gem).
2. If you set a custom Accept-Encoding header, then Net::Http expects that you will handle the decoding part yourself, so it won't decompress the response see code. I have updated my PR to manually decompress the response if the user specified Accept-Encoding as described here, and it fixes the above issue. However, it adds extra complexity to your SDK.

What do you think - should the SDK handle the decoding and support, or is there something that can be done on the API server itself?

[lilith]

Rest-client has been abandoned for 5 years, which is an eternity in HTTP security. At one point it contained malicious code: https://www.securityweek.com/backdoor-found-rest-client-ruby-gem/

Consider Faraday or something maintained? There are active forks, I think

https://github.com/rest-client/rest-client/issues/764

On Sun, Sep 8, 2024, 9:06 AM cb-alish @.***> wrote:

Hi @lilith https://github.com/lilith, please use the following code to reproduce the issue. Ensure that you are using chargebee-ruby version v2.8.6.

subscription = ChargeBee::Subscription.retrieve("{your-subscription-id}", nil, { "Accept-Encoding" => "gzip"})

— Reply to this email directly, view it on GitHub https://github.com/chargebee/chargebee-ruby/issues/43#issuecomment-2336679799, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA2LH2CSZ4PPE4SYSZUTHTZVRDU5AVCNFSM6AAAAABN26INVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZWGY3TSNZZHE . You are receiving this because you were mentioned.Message ID: @.***>

[cb-alish]

Hi @loomchild , ideally, gzip responses should be handled by the http client itself. Since rest-client doesn't support that, we have no other option but to manually add that logic. My concern is about other potential breaking changes in the newer versions of rest-client. We'll test your PR and keep you updated on the progress

[cb-alish]

Hi @lilith , thanks for the suggestion. The minimum required Ruby version for Faraday is 3.0 or higher, but many of our users are on earlier Ruby versions. We'll be evaluating the options in the near future

[lilith]

https://github.com/rest-man/rest-man

[cb-alish]

Closing this issue as we've moved from rest-client to native Net::HTTP since v2.49.0. Sorry for the delay in execution. Please feel free to reopen or post in the issue section if you encounter any problems.