jnunemaker/httparty · warning

[DEPRECATION] HTTParty will no longer override `response#nil

Error message

[DEPRECATION] HTTParty will no longer override `response#nil?`. This functionality will be removed in future versions. Please, add explicit check `response.body.nil? || response.body.empty?`. For more info refer to: https://github.com/jnunemaker/httparty/issues/568
#{trace_line}

What it means

This is not an exception but a deprecation warning printed (via Kernel#warn, including the caller's trace line) whenever HTTParty::Response#nil? is invoked. Response#nil? historically returned true for empty bodies, which conflates 'no response' with 'empty body'; httparty will stop overriding nil?, so the warning tells you to replace `response.nil?` checks with an explicit `response.body.nil? || response.body.empty?` before upgrading. Once the override is removed, truthy Response objects will behave like normal Ruby objects under nil checks.

Source

Thrown at lib/httparty/response.rb:151

    end

    def throw_exception
      if @request.options[:raise_on].to_a.detect { |c| code.to_s.match(/#{c.to_s}/) }
        ::Kernel.raise ::HTTParty::ResponseError.new(@response), "Code #{code} - #{body}"
      end
    end

    private

    def warn_about_nil_deprecation
      trace_line = caller.reject { |line| line.include?('httparty') }.first
      warning = "[DEPRECATION] HTTParty will no longer override `response#nil?`. " \
        "This functionality will be removed in future versions. " \
        "Please, add explicit check `response.body.nil? || response.body.empty?`. " \
        "For more info refer to: https://github.com/jnunemaker/httparty/issues/568\n" \
        "#{trace_line}"

      warn(warning)
    end
  end
end

require 'httparty/response/headers'

View on GitHub (pinned to 8f4a09e343)

Solutions

1. Replace `response.nil?` with `response.body.nil? || response.body.empty?` (the exact check the message prescribes).
2. Wrap the intent in a helper: `def empty_response?(r) = r.body.nil? || r.body.empty?` and use it everywhere.
3. After migrating, upgrade httparty and confirm the warning no longer appears in logs.

Example fix

# before
resp = Api.get('/jobs')
return [] if resp.nil?          # triggers DEPRECATION warning

# after
resp = Api.get('/jobs')
return [] if resp.body.nil? || resp.body.empty?

def empty_response?(resp)
  resp.body.nil? || resp.body.empty?
end

return [] if empty_response?(Api.get('/jobs'))

When it happens

Trigger: Any code doing `if resp.nil?`, `unless response`, `resp || default`, or `Array.wrap(response)` on an HTTParty::Response whose body is nil or empty — including `puts resp` style debugging that goes through nil? indirectly.

Common situations: Long-lived codebases from the httparty era where `response.nil?` was the idiomatic empty-body check, boolean coercion in templates or presenters, and gems that call .nil? on arbitrary objects (serializers, loggers) now triggering noisy warnings against httparty responses.

Related errors

• #{response}
• Default params must be an object which responds to #to_hash
• Headers must be an object which responds to #to_hash
• Cookies must be an object which responds to #to_hash
• The URI adapter should respond to #parse

AI-assisted analysis of jnunemaker/httparty@8f4a09e343 (2026-08-21). Data as JSON: /api/errors/f648487ccb2a69b4. Report an issue: GitHub.