GO — Healthy across all four use cases

• 15 active contributors
• ISC licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Concentrated ownership — top contributor handles 52% of recent commits
• ⚠ Scorecard: marked unmaintained (0/10)

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

httpbin is a lightweight HTTP request/response inspection service written in Python + Flask that echoes back details about incoming HTTP requests (headers, method, body, cookies, etc.) and serves synthetic HTTP responses for testing. It's deployed at httpbin.org and commonly used by developers to test HTTP clients, libraries, and tools without needing a real backend. Single Flask application in httpbin/ directory: httpbin/core.py contains route handlers and business logic, httpbin/helpers.py and httpbin/utils.py provide utilities, httpbin/filters.py handles template filters, httpbin/structures.py defines data structures. HTML templates live in httpbin/templates/ with static assets in httpbin/static/. Entry point is httpbin/init.py. Containerized via Dockerfile and docker-compose.yml for deployment.

Python developers, SDK maintainers (like the requests library team), and anyone building HTTP clients who need a reliable echo service to validate request/response handling, status codes, redirects, authentication flows, and edge cases without mocking.

Production-ready and stable. This is Kenneth Reitz's project (requests library author) with official deployment at httpbin.org, Docker Hub distribution, Travis CI integration, and test coverage via test_httpbin.py. It's a reference service in the Python HTTP ecosystem.

Low maintenance risk because the service is simple and largely feature-complete—it echoes requests rather than executing complex logic. However, there's single-maintainer risk (Kenneth Reitz), and the repo shows Python 95% code with minimal dependencies visible in the file list (Pipfile exists but details are sparse). No breaking changes appear imminent, but check Pipfile.lock for dependency versions.

No specific recent activity visible from the file list (no CHANGELOG or timestamp data provided). The repo appears mature and in maintenance mode rather than active feature development. Check Git history and open PRs on GitHub for current work.

Clone and run via Docker: docker pull kennethreitz/httpbin && docker run -p 80:80 kennethreitz/httpbin. Alternatively, clone the repo, install dependencies with pip install -r requirements.txt (inferred from Pipfile), then run with python -m httpbin or flask run if setup.py is configured as an entry point.

Daily commands: Local development: pip install -e . (from setup.py), then FLASK_APP=httpbin flask run or check Procfile for gunicorn httpbin:app. Docker: docker-compose up (docker-compose.yml present). Production: served via Heroku (Procfile + runtime.txt) or Docker Hub.

• httpbin/core.py — Primary Flask application with all HTTP endpoint definitions and request handling logic—must understand this to add any new routes or modify existing behavior.
• httpbin/__init__.py — Application factory and initialization entry point—defines how the Flask app is created and configured.
• setup.py — Package metadata and dependency definitions—critical for understanding build, installation, and Python version requirements.
• httpbin/helpers.py — Utility functions for request inspection, response formatting, and common HTTP operations used across endpoints.
• Dockerfile — Container build configuration showing runtime environment, dependencies, and deployment instructions.
• test_httpbin.py — Test suite covering endpoint behavior and edge cases—essential for validating changes and understanding expected behavior.
• httpbin/filters.py — Jinja2 template filters for response formatting and HTML rendering—used in HTML response generation.

• Flask App (core.py) (Flask, Werkzeug, jsonify, render_template) — Registers all HTTP endpoints, routes requests to handlers, serializes responses (JSON/HTML), manages status codes and headers
  • Failure mode: If a route handler raises an exception, Flask returns 500 error; missing routes return 404; invalid JSON input may cause parsing errors.
• Request Introspection (helpers.py) (Flask request object, base64, re (regex)) — Extracts data from incoming request: headers, query params, form data, JSON body, client IP, auth credentials
  • Failure mode: Malformed auth headers or invalid encoding may fail to parse; missing expected fields return None; base64 decode errors propagate.
• Template Rendering (filters.py + templates/) (Jinja2, Flask template filters) — Converts context data into HTML using Jinja2; applies custom filters for formatting (e.g., escape, uppercase)
  • Failure mode: Template syntax errors cause TemplateError; missing context variables render empty; circular includes cause recursion error.
• Test Suite (test_httpbin.py) (pytest, requests library, Flask test client) — Validates all endpoints return correct status codes, response formats, and handle edge cases (auth, redirects, large payloads)
  • Failure mode: Test failures indicate endpoint regression; failures in CI/CD prevent deployment; missing tests create coverage gaps.

• Client (browser/curl) → Flask route handler (core.py) — HTTP request with headers, query params, body, method; Flask parses and injects into request context
• Flask route handler → Helpers (helpers.py) — Handler calls helper functions to extract request data (auth, headers, args, IP) for response building
• Helpers + handler logic → jsonify() or render_template() — Assembled data (dict or context) passed to serializer: jsonify() for JSON responses, render_template() for HTML

Add a new HTTP endpoint (e.g., GET /api/custom)

1. Open httpbin/core.py and locate the @app.route() decorators (httpbin/core.py)
2. Add a new @app.route('/custom') function that uses jsonify() or render_template() from httpbin/helpers.py to build the response (httpbin/core.py)
3. Use request introspection helpers (e.g., request.headers, request.args) to inspect incoming data (httpbin/helpers.py)
4. Add test cases in test_httpbin.py with GET/POST calls to /custom to validate the endpoint (test_httpbin.py)

Add a new HTML response page

1. Create a new .html file in httpbin/templates/ (e.g., custom-page.html) following the existing template structure (httpbin/templates/index.html)
2. In httpbin/core.py, add a @app.route() that calls render_template('custom-page.html') with context data (httpbin/core.py)
3. If you need custom formatting filters, register them in httpbin/filters.py using @app.template_filter() (httpbin/filters.py)

Add new helper functions for request processing

1. Add utility function to httpbin/helpers.py (e.g., parse_auth_header(), format_response()) (httpbin/helpers.py)
2. Import and call the new helper in httpbin/core.py endpoint handlers (httpbin/core.py)
3. Add unit tests in test_httpbin.py to verify helper behavior with edge cases (test_httpbin.py)

Extend with custom response structure

1. Define new data structure or response model in httpbin/structures.py (httpbin/structures.py)
2. Use the new structure in httpbin/core.py endpoints via jsonify() or dict conversion (httpbin/core.py)
3. Test serialization and response format in test_httpbin.py (test_httpbin.py)

• Flask — Lightweight Python web framework ideal for rapid prototyping of HTTP testing utility with minimal boilerplate; easy to add routes and customize responses.
• Jinja2 templating — Standard Flask templating engine for rendering HTML demo pages and dynamic content without coupling to the API response format.
• Docker & Gunicorn — Containerization ensures reproducible deployment; Gunicorn provides WSGI production server for handling concurrent requests.
• pytest — Python standard testing framework for automated validation of endpoint behavior, response formats, and edge cases.

• Single monolithic core.py file with all routes

  • Why: Simplicity and discoverability—all endpoints visible in one place for reference and debugging.
  • Consequence: File becomes large (1000+ lines) and less modular; refactoring into blueprints would improve maintainability but increase complexity.

• In-memory request inspection without persistence

  • Why: Stateless design allows horizontal scaling and no database dependency; every request is independent.
  • Consequence: No request history or logging; cannot track patterns or debug issues post-request; each client must capture responses manually.

• Mix of JSON and HTML responses in same endpoints

  • Why: Flexible response format allows browser testing and programmatic testing from same URL (Accept header negotiation).
  • Consequence: Template rendering adds latency for HTML responses; code must handle multiple output formats.

• Does not persist request history or provide webhooks; is stateless and ephemeral.
• Does not provide authentication or authorization; all endpoints are publicly accessible.
• Does not simulate realistic backend behavior (caching, rate limiting, complex processing); is a reflection service only.
• Not intended for production API mocking; use a dedicated mock server framework for that.
• Does not handle file uploads or large payloads beyond HTTP/1.1 limits.

No environment variables or external services required—httpbin is intentionally stateless and self-contained. Flask debug mode should be disabled in production (check core.py or wsgi config). The Pipfile exists but Pipfile.lock specifics are not shown—ensure locked dependencies match your Python version (runtime.txt may specify 3.6 or later). Docker setup assumes port 80 is available; use -p flag to remap. Flasgger integration expects Flask routes to have docstrings for Swagger documentation—missing docstrings = missing API docs.

• HTTP Status Code Semantics — httpbin's primary purpose is serving synthetic status codes (200, 301, 404, 500, etc.) to test client handling—understanding semantics (e.g., 3xx redirects vs. 4xx client errors) is critical for using the service correctly
• CORS and Same-Origin Policy — httpbin serves cross-origin requests and needs to handle CORS headers correctly for testing browser-based HTTP clients; core.py likely includes CORS middleware
• HTTP Request/Response Headers Inspection — The core value of httpbin is echoing request headers, cookies, and body back to the client—helpers.py and core.py must correctly parse Flask request objects and format responses
• Flask Request Context and Decorators — All httpbin routes use Flask's request context and decorators; understanding @app.route(), request.method, request.headers, and request.get_json() is essential for extending the service
• Content Negotiation (Accept Headers) — httpbin likely returns JSON, XML, or HTML based on Accept headers; core.py must implement content-type switching to serve different formats for the same endpoint
• Base64 and URL Encoding — httpbin includes endpoints for testing encoding/decoding (UTF-8-demo.txt, base64 auth); utils.py likely wraps Python's base64 and urllib modules
• Docker Containerization and Multi-Stage Builds — Dockerfile defines the production runtime; understanding layer caching, EXPOSE, ENTRYPOINT, and CMD is needed to modify deployment

• kennethreitz/requests — Canonical Python HTTP client library; httpbin is the de facto test server for requests' test suite
• python-httplib2/httplib2 — Alternative HTTP client library that also uses httpbin-like services for testing
• postman-echo/echo-server — Postman's own echo/inspect service alternative to httpbin, comparable feature set for request testing
• kennethreitz/responder — Kenneth Reitz's modern ASGI alternative to Flask; shows evolution of his web framework philosophy
• pallets/flask — Core Flask framework httpbin is built on; understanding Flask internals (blueprints, context, request handling) is essential

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 httpbin/helpers.py and httpbin/filters.py

The repo has test_httpbin.py but it likely focuses on endpoint testing. helpers.py and filters.py contain utility functions and Jinja2 filters that lack dedicated unit test coverage. This improves maintainability and reduces regressions when modifying these utilities.

• [ ] Examine existing test_httpbin.py to understand current test patterns and fixtures
• [ ] Create test cases for each function in httpbin/helpers.py (e.g., parsing, validation helpers)
• [ ] Create test cases for each filter in httpbin/filters.py (e.g., date formatting, string manipulation)
• [ ] Run tests with tox.ini configuration to ensure compatibility
• [ ] Achieve >85% code coverage for both files and document coverage metrics

Migrate from Travis CI (.travis.yml) to GitHub Actions workflow

The repo uses outdated .travis.yml for CI/CD. GitHub Actions is now the standard, provides better integration with GitHub, and offers free minutes for public repos. This modernizes the development workflow without breaking existing functionality.

• [ ] Create .github/workflows/test.yml to run tox tests on Python 3.8+ across Linux/macOS
• [ ] Create .github/workflows/docker-build.yml to build and validate Dockerfile on commits
• [ ] Configure the workflow to run on push to master and all pull requests
• [ ] Test locally that Docker image builds successfully using docker-compose.yml
• [ ] Update README.md to replace Travis CI badge with GitHub Actions badge
• [ ] Keep .travis.yml for backward compatibility during transition period

Add integration tests for Docker deployment in test_httpbin.py

The Dockerfile and docker-compose.yml exist but lack automated validation that the containerized app functions correctly. Current test_httpbin.py tests the application code but not the deployment configuration, risking broken Docker images.

• [ ] Review existing test_httpbin.py structure and fixture setup
• [ ] Add pytest test cases that verify Dockerfile builds without errors
• [ ] Add test cases that spin up a container via docker-compose and verify key endpoints respond correctly (e.g., GET /get, POST /post, /status/200)
• [ ] Test that environment variables and port mappings work as documented in README.md
• [ ] Verify the published image at kennethreitz/httpbin works with the same tests
• [ ] Integrate these tests into the CI workflow (via the GitHub Actions PR above)

• Add comprehensive docstrings to all routes in httpbin/core.py for Flasgger Swagger generation—currently only some endpoints are documented, leaving parts of the API undocumented in the interactive UI.
• Expand test_httpbin.py to cover edge cases for response headers (e.g., custom header echo, header encoding, very long headers) and request size limits not yet tested.
• Create missing HTML template for /links endpoint shown in templates/index.html but verify if route in core.py generates synthetic link trees—if not, implement the feature and template.

• High · Outdated Base Image (Ubuntu 18.04) — Dockerfile, line 1. The Dockerfile uses Ubuntu 18.04 which reached end-of-standard-support in April 2023. This image may contain unpatched security vulnerabilities and will not receive security updates. Fix: Upgrade to Ubuntu 22.04 LTS or use a more recent Python base image such as 'python:3.11-slim' which is smaller and better maintained for Python applications.
• High · Missing Container Security Context — Dockerfile. The Docker container runs without specifying a non-root user. The application runs as root, which violates the principle of least privilege and increases the risk of privilege escalation attacks. Fix: Add a non-root user and switch to it before running the application: 'RUN useradd -m -u 1000 httpbin && USER httpbin' before the CMD instruction.
• High · Exposed Port on 0.0.0.0 — Dockerfile, CMD line. The Gunicorn server binds to 0.0.0.0:80, exposing the application to all network interfaces. In production, this should be restricted or placed behind a reverse proxy with proper access controls. Fix: Use a reverse proxy (nginx/Apache) or API gateway in front of the application. Consider binding to specific interfaces or using environment variables for configuration.
• High · No Dependency Version Pinning Visible — Dockerfile, Pipfile/Pipfile.lock (content not provided). The Dockerfile installs pipenv without specifying a version and relies on 'pipenv lock -r' for dependency resolution. However, without visible Pipfile/Pipfile.lock content, the actual dependency versions cannot be verified for known vulnerabilities. Fix: Ensure all dependencies in Pipfile.lock are pinned to specific versions. Regularly scan dependencies with tools like 'safety', 'pip-audit', or Snyk for known vulnerabilities.
• Medium · Missing Security Headers Configuration — httpbin/core.py, httpbin/templates. Based on the file structure and typical Flask applications, there is no visible implementation of security headers (Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, etc.) in template or core files. Fix: Implement security headers middleware or Flask extensions like 'flask-talisman' to add headers such as CSP, HSTS, X-Frame-Options, and X-Content-Type-Options.
• Medium · Potential XSS Vulnerability in Templates — httpbin/templates/ (especially trackingscripts.html, forms-post.html). The application includes templates that may render user-supplied HTTP request data. If data is not properly escaped (e.g., in trackingscripts.html or forms-post.html), XSS vulnerabilities could exist. Fix: Audit all templates to ensure user-controlled data is properly escaped using Jinja2's auto-escape feature. Verify that {{ }} syntax is used instead of raw data injection.
• Medium · Missing HTTPS/TLS Configuration — Dockerfile, docker-compose.yml. The Docker configuration and exposed port default to HTTP (port 80). In production, HTTPS should be enforced to protect request/response data in transit. Fix: Configure TLS termination using a reverse proxy (nginx with SSL) or enable HTTPS in the application. Expose port 443 and redirect HTTP to HTTPS.
• Medium · No Input Validation/Sanitization Visible — httpbin/core.py, httpbin/helpers.py. As an HTTP request/response service, httpbin echoes back user-supplied data. Without visible input validation in core.py or helpers.py, there may be risks of injection attacks or malicious data propagation. Fix: Implement input validation for all endpoints that accept user data. Set size limits on request bodies and validate headers for expected formats.
• Low · Missing HEALTHCHECK Instruction — Dockerfile. The Dockerfile does not include a HEALTHCHECK instruction, making it difficult for orchestration platforms to detect unhealthy containers automatically. Fix: Add a

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

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

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/postmanlabs/httpbin 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.

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

What it runs against: a local clone of postmanlabs/httpbin — 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 postmanlabs/httpbin | Confirms the artifact applies here, not a fork | | 2 | License is still ISC | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 747 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of postmanlabs/httpbin. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/postmanlabs/httpbin.git
#   cd httpbin
#
# 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 postmanlabs/httpbin and re-run."
  exit 2
fi

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

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

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

# 4. Critical files exist
test -f "httpbin/core.py" \\
  && ok "httpbin/core.py" \\
  || miss "missing critical file: httpbin/core.py"
test -f "httpbin/__init__.py" \\
  && ok "httpbin/__init__.py" \\
  || miss "missing critical file: httpbin/__init__.py"
test -f "setup.py" \\
  && ok "setup.py" \\
  || miss "missing critical file: setup.py"
test -f "httpbin/helpers.py" \\
  && ok "httpbin/helpers.py" \\
  || miss "missing critical file: httpbin/helpers.py"
test -f "Dockerfile" \\
  && ok "Dockerfile" \\
  || miss "missing critical file: Dockerfile"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 747 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~717d)"
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/postmanlabs/httpbin"
  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).

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