If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/jnunemaker/httparty shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 2mo ago
• 26+ active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 67% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live jnunemaker/httparty repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/jnunemaker/httparty.

What it runs against: a local clone of jnunemaker/httparty — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in jnunemaker/httparty | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 96 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of jnunemaker/httparty. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/jnunemaker/httparty.git
#   cd httparty
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of jnunemaker/httparty and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "jnunemaker/httparty(\\.git)?\\b" \\
  && ok "origin remote is jnunemaker/httparty" \\
  || miss "origin remote is not jnunemaker/httparty (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "lib/httparty.rb" \\
  && ok "lib/httparty.rb" \\
  || miss "missing critical file: lib/httparty.rb"
test -f "lib/httparty/request.rb" \\
  && ok "lib/httparty/request.rb" \\
  || miss "missing critical file: lib/httparty/request.rb"
test -f "lib/httparty/response.rb" \\
  && ok "lib/httparty/response.rb" \\
  || miss "missing critical file: lib/httparty/response.rb"
test -f "lib/httparty/parser.rb" \\
  && ok "lib/httparty/parser.rb" \\
  || miss "missing critical file: lib/httparty/parser.rb"
test -f "lib/httparty/connection_adapter.rb" \\
  && ok "lib/httparty/connection_adapter.rb" \\
  || miss "missing critical file: lib/httparty/connection_adapter.rb"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 96 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~66d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/jnunemaker/httparty"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

HTTParty is a Ruby gem that wraps Net::HTTP to make HTTP requests and API integration dramatically simpler. It eliminates boilerplate by providing a clean DSL for GET/POST/PUT/DELETE requests, automatic response parsing (JSON/XML), and easy integration into Ruby classes via include HTTParty. Core capability: define base_uri and default_params once, then make type-safe requests with minimal syntax. Flat monorepo structure: lib/ contains the core HTTParty module and request/response handling, examples/ provides runnable recipes for common tasks (twitter.rb, multipart.rb, logging.rb, etc.), features/ houses integration tests using Gherkin (basic_authentication.feature, handles_compressed_responses.feature), and bin/httparty is a CLI entry point for ad-hoc requests.

Ruby developers building API clients and integrations—from one-off scripts to production services. They want to avoid wrestling with Net::HTTP plumbing and need readable, maintainable code for consuming REST APIs (StackExchange, Twitter, AWS, etc. as shown in examples/).

Production-ready and actively maintained. The repo shows comprehensive test coverage via Cucumber features (15K+ lines), CI/CD pipelines in .github/workflows/ci.yml, and a stable codebase (298K lines Ruby). However, commit recency should be verified; the age and issue backlog would determine if it's still receiving updates or in maintenance-only mode.

Low risk for core functionality—HTTParty is a single-purpose wrapper with no external gem dependencies listed. Main risk: single maintainer (jnunemaker) means feature requests or critical security bugs could stall. Ruby version constraint (≥2.7.0) is reasonable but should be monitored as Ruby 3.x matures. No breaking changes are obvious from the file structure.

Cannot determine from provided data. Check GitHub Actions in .github/workflows/ci.yml for recent build status and the Changelog.md for recent version notes. The presence of .github/dependabot.yml indicates active dependency management.

git clone https://github.com/jnunemaker/httparty.git
cd httparty
bundle install
bundle exec rake

Then explore examples/ (e.g., ruby examples/basic.rb) or run bundle exec cucumber to see integration tests.

Daily commands: No server to start. This is a library. Run tests: bundle exec rake (standard Rakefile). Run CLI: bundle exec httparty 'https://api.example.com/endpoint'. Run examples: cd examples && ruby basic.rb.

• lib/httparty.rb — Entry point and main module that provides the HTTParty DSL and class methods for HTTP requests—every contributor must understand the public API.
• lib/httparty/request.rb — Core request handling logic that orchestrates HTTP operations, parameter processing, and response handling—the heart of the library.
• lib/httparty/response.rb — Response abstraction wrapping Net::HTTP responses with parsing, header handling, and convenience methods—essential for understanding how results are delivered.
• lib/httparty/parser.rb — Handles response body parsing (JSON, XML, CSV, etc.) and custom parser registration—critical for format support.
• lib/httparty/connection_adapter.rb — Manages Net::HTTP connection setup, SSL/TLS configuration, and actual socket communication—foundation of network reliability.
• lib/httparty/exceptions.rb — Defines HTTParty-specific exception hierarchy used throughout the codebase for error handling.

Add support for a new response format

1. Create a parser method in lib/httparty/parser.rb that detects and parses your format (e.g., MessagePack, Protocol Buffers) (lib/httparty/parser.rb)
2. Register the format in the parser's format detection logic (check content-type, file extension, or custom rules) (lib/httparty/parser.rb)
3. Update examples to show usage and add integration tests in spec/httparty/parser_spec.rb (spec/httparty/parser_spec.rb)

Add a custom authentication scheme

1. Create a new module in lib/httparty/ (e.g., custom_auth.rb) or extend lib/httparty/net_digest_auth.rb (lib/httparty/net_digest_auth.rb)
2. Implement the auth logic (header building, token generation) and expose it as a request option (lib/httparty/request.rb)
3. Update lib/httparty.rb to document the new option and add it to default_params if needed (lib/httparty.rb)
4. Add a feature test in features/ to verify the authentication flow (features/basic_authentication.feature)

Add a custom request/response logging formatter

1. Create a new formatter class in lib/httparty/logger/ (e.g., custom_formatter.rb) inheriting from or using the logger interface (lib/httparty/logger/logger.rb)
2. Implement the format method to output logs in your desired style (JSON, custom text, etc.) (lib/httparty/logger/logger.rb)
3. Register the formatter in the logger registry and add usage example in examples/logging.rb (examples/logging.rb)
4. Add unit tests in spec/httparty/logger/ to verify formatting output (spec/httparty/logger_spec.rb)

Add support for a new HTTP feature (streaming, chunked encoding, etc.)

1. Extend lib/httparty/request.rb with the feature logic (e.g., chunked encoding setup in build_request) (lib/httparty/request.rb)
2. If the feature needs special body handling, update lib/httparty/request/body.rb or create a new body handler (lib/httparty/request/body.rb)
3. Expose the feature as an option in lib/httparty.rb class methods and update response handling in lib/httparty/response.rb if needed (lib/httparty.rb)
4. Add an example in examples/ and a feature test in features/ (examples/basic.rb)

• Net::HTTP (Ruby stdlib) — Built-in, no external C dependencies, provides robust HTTP/1.1 with SSL/TLS and digest auth support; HTTParty wraps it for ease of use.
• Nokogiri (optional) — Industry standard for XML/HTML parsing; HTTParty auto-detects and uses it if available for better DOM manipulation.
• JSON (stdlib) — Built-in JSON parsing for modern REST APIs; HTTParty delegates to stdlib's JSON module.
• Cucumber & RSpec — BDD and unit testing frameworks; extensive feature tests for integration scenarios and unit specs for individual components.

• Wrapping Net::HTTP rather than using HTTP or Faraday

  • Why: Minimize dependencies while providing a clean DSL; HTTParty is lightweight and self-contained.
  • Consequence: Some advanced features (like HTTP/2) are unavailable; contributors cannot rely on newer HTTP libraries but gain simplicity.

• Format detection by Content-Type header rather than strict parsing

  • Why: Faster for common cases (JSON APIs always send application/json); graceful fallback to raw body.
  • Consequence: Mismatched Content-Type headers can cause parse failures; users must validate or override format explicitly.

• Class-level DSL (base_uri, default_params, headers) with instance-level options

  • Why: Provides both convenience (DRY setup) and flexibility (per-request overrides).
  • Consequence: Method resolution order requires careful inheritance; options merging can be non-obvious for deeply nested classes.

• Synchronous, blocking requests only

  • Why: Simplicity and predictability; Net::HTTP is blocking by default.
  • Consequence: Not suitable for high-concurrency scenarios; async patterns require external solutions or refactoring.

• Does not provide HTTP/2 or HTTP/3 support (relies on Net::HTTP's HTTP/1.1).
• Not a real-time or streaming-first library; streaming multipart is supported but not the primary use case.
• Does not handle GraphQL, gRPC, or WebSocket protocols natively.
• Not designed for server-side request forgery (SSRF) prevention; users are responsible for input validation.
• Does not provide automatic retries or circuit breaker patterns (though examples show how to wrap for this).

No obvious environment variables or service dependencies. Potential gotchas: (1) SSL certificate validation is on by default—tests using self-signed certs must disable it with ssl_version: :SSLv3 or similar (see examples/peer_cert.rb). (2) Timeout behavior: default timeouts may not suit slow APIs—set timeout: N per request. (3) Logging requires explicit setup (see examples/logging.rb)—HTTParty does not log HTTP traffic by default. (4) The CLI (bin/httparty) may need manual build/install steps depending on gem installation method.

• Module Inclusion / Mixins — HTTParty is used via include HTTParty in a class, not instantiation; understanding Ruby's mixin pattern is essential to use and modify HTTParty
• Net::HTTP (Ruby stdlib) — HTTParty wraps stdlib's Net::HTTP; understanding its Request/Response model helps debug low-level issues and understand redirects/auth
• HTTP Digest Authentication — HTTParty supports digest auth (not just basic); features/digest_authentication.feature tests this; relevant for secure API integrations
• Content Negotiation & Automatic Serialization — HTTParty auto-detects and parses JSON/XML responses based on Content-Type headers; knowing how this works prevents format surprises
• HTTP Redirects (3xx Status Codes) — HTTParty handles 301/302/307 redirects transparently by default; features/supports_redirection.feature covers this; important for APIs that redirect
• Gherkin / Behavior-Driven Development — The entire test suite uses Cucumber .feature files (15K lines); contributing tests requires writing Gherkin scenarios and Ruby step definitions
• Streaming & Chunked Transfer — HTTParty supports streaming downloads (examples/stream_download.rb) and body streams (examples/body_stream.rb); relevant for large file transfers

• ruby-http/http — Direct competitor: similar HTTP DSL in pure Ruby, arguably more modern API but less battle-tested in production
• rest-client/rest-client — Older Ruby HTTP client offering a simpler block-based DSL; HTTParty evolved partly as a response to this
• jnunemaker/crack — Companion gem (also by jnunemaker) for parsing XML/JSON—HTTParty depends on or pairs with this for serialization
• lostisland/faraday — Modern middleware-based HTTP client with adapter pattern; used when you need pluggable drivers (Net::HTTP, Typhoeus, etc.)
• cucumber/cucumber-ruby — Testing framework used throughout HTTParty's feature suite; understanding Gherkin is essential for contributing tests

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for lib/httparty/logger module

The logger module has 4 formatter classes (apache_formatter.rb, curl_formatter.rb, logstash_formatter.rb, and logger.rb) but there's no visible dedicated test file for them in the repo structure. Given the importance of logging for debugging HTTP requests, adding unit tests for each formatter would improve test coverage and ensure formatters work correctly across Ruby versions.

• [ ] Create spec/httparty/logger/apache_formatter_spec.rb with tests for log output format
• [ ] Create spec/httparty/logger/curl_formatter_spec.rb with tests for curl command generation
• [ ] Create spec/httparty/logger/logstash_formatter_spec.rb with tests for logstash JSON output
• [ ] Add integration test in features/ verifying logger output with real HTTP requests
• [ ] Verify tests run in CI pipeline (.github/workflows/ci.yml)

Add tests and documentation for multipart request handling in lib/httparty/request.rb

The examples directory contains examples/multipart.rb showing multipart functionality, but there's no visible dedicated feature test or comprehensive unit tests for multipart request edge cases. This is a critical feature for file uploads that deserves robust test coverage and clear examples.

• [ ] Create features/multipart_requests.feature covering file uploads, multiple files, and mixed content-type scenarios
• [ ] Add unit tests in spec/httparty/request_spec.rb specifically for multipart boundary generation and encoding
• [ ] Add a feature step file in features/steps/ for multipart-specific test helpers
• [ ] Expand examples/multipart.rb with more realistic use cases (image upload, form data with files)
• [ ] Document multipart usage in docs/README.md with common patterns and pitfalls

Add GitHub Actions workflow for testing against multiple Ruby versions and HTTP client backends

The .github/workflows/ci.yml exists but based on the repo structure, it may not comprehensively test against all supported Ruby versions (2.7.0+) and various HTTP backend configurations. Adding a matrix strategy would catch version-specific bugs early and ensure compatibility across environments.

• [ ] Update .github/workflows/ci.yml to add matrix strategy testing Ruby 2.7, 3.0, 3.1, 3.2, 3.3
• [ ] Add conditional test steps for different Gemfile variants if multiple exist (Gemfile.lock, Gemfile-rails-6, etc.)
• [ ] Add linting job using existing .rubocop.yml and .rubocop_todo.yml configurations
• [ ] Add test coverage reporting step (simplecov or similar) to track coverage trends
• [ ] Document Ruby version support in README.md based on tested versions

• Add integration test for HTTP/2 support in features/ (spec examples under HTTP/2 scenarios); currently only HTTP/1.1 is evident.
• Expand examples/custom_parsers.rb with a real Nokogiri HTML parser example—examples/nokogiri_html_parser.rb exists but lacks documentation linking to it from the main README.
• Add a missing feature: document and test the follow_redirects: false option behavior end-to-end in features/supports_redirection.feature to clarify what response is returned without following.

HTTParty is a well-maintained HTTP client library with a moderate security posture. The library itself has no critical vulnerabilities, but security depends heavily on how consuming applications use it. Main concerns are: (1) SSRF/injection risks if user input isn't validated before creating requests, (2) potential MITM vulnerabilities if HTTPS certificate verification isn't enabled, (3) sensitive data exposure through logging, and (4) file upload security depending on application implementation. The library provides security features but requires developers to use them correctly. No hardcoded credentials or insecure dependencies were identified in the provided file structure. Overall, this is a relatively secure library with typical responsibility-sharing between the library and consuming applications.

• Medium · Potential HTTP Request Injection via User-Controlled URIs — lib/httparty.rb, lib/httparty/request.rb. HTTParty is an HTTP client library that makes requests based on user-provided URIs and parameters. If user input is not properly validated before being passed to HTTParty methods (get, post, etc.), it could lead to SSRF (Server-Side Request Forgery) or other injection attacks. The library itself doesn't validate or sanitize URIs. Fix: Implement strict URI validation in consuming applications. Whitelist allowed domains/protocols. Use URI parsing and validation before passing to HTTParty methods. Never directly interpolate user input into request URIs.
• Medium · Missing Certificate Validation Controls — lib/httparty/connection_adapter.rb, examples/peer_cert.rb. The library supports peer certificate validation (evidenced by examples/peer_cert.rb), but there's no indication of enforced certificate validation by default. Applications using HTTParty for HTTPS requests might be vulnerable to MITM attacks if certificate verification is not explicitly enabled. Fix: Ensure SSL certificate verification is enabled by default. Document the importance of certificate validation. Warn users about disabling verification in production.
• Medium · Potential Sensitive Data Exposure in Logging — lib/httparty/logger/. The library includes comprehensive logging capabilities (Apache formatter, cURL formatter, Logstash formatter). If logging is enabled with verbose settings, sensitive data such as authentication tokens, API keys, or personal information in request/response bodies could be exposed in logs. Fix: Implement log filtering/redaction for sensitive headers (Authorization, API-Key, etc.) and request parameters. Document security implications of enabling verbose logging in production. Provide sanitization utilities for logs.
• Low · Example Files May Contain Hardcoded Credentials — examples/*.rb. Multiple example files demonstrate API usage (Twitter, Delicious, Tripit, etc.). While not vulnerabilities in the library itself, developers might copy-paste examples and accidentally commit real credentials. Fix: Use placeholder values in all examples (e.g., YOUR_API_KEY, YOUR_TOKEN). Add clear comments warning against committing credentials. Consider adding pre-commit hooks or scanning tools to detect hardcoded secrets.
• Low · Missing Security Headers Guidance — lib/httparty/response.rb, docs/. There is no evidence of documentation or default handling for security-related HTTP headers that should be validated in responses (HSTS, CSP, etc.). Fix: Add documentation on security best practices when using HTTParty. Recommend validating security headers from responses. Consider adding helper methods for common security header validations.
• Low · Multipart Upload Handling — lib/httparty/request/multipart_boundary.rb, lib/httparty/request/streaming_multipart_body.rb. The library supports multipart uploads (lib/httparty/request/streaming_multipart_body.rb). If not properly validated on the consuming application side, this could be exploited for file upload attacks. Fix: Document secure file upload practices. Recommend file type validation, size limits, and virus scanning on the application/server side. Remind users that HTTParty is just a transport layer.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.