Evaluation Dataset: Claude vs OpenAI Codex

HTTPie CLI
This is HTTPie — a human-friendly command-line HTTP client written in Python. It exposes three commands: http, https, and httpie.

Main Components

httpie/core.py — Entry point / request lifecycle
The central orchestrator. Parses arguments, builds the HTTP request, sends it, and pipes the response to the output layer.

httpie/cli/ — Argument parsing & syntax
- argparser.py / definition.py: Defines the CLI surface (flags, options, help text)
- requestitems.py: Parses HTTPie's expressive key-value syntax (e.g. name=value, name:=json, header:value) into request components
- nested_json/: Handles nested JSON body construction from CLI args

httpie/client.py — HTTP engine
Wraps the requests library to send HTTP requests with support for auth, proxies, SSL/TLS, and streaming.

httpie/output/ — Response formatting & display
- processing.py: Routes response parts (headers, body) through the formatter pipeline
- formatters/: Pretty-printers for JSON, XML, headers, etc.
- streams.py: Handles streamed vs. buffered output modes
- writer.py: Writes final output to stdout/file
- ui/: Rich terminal UI elements (spinners, panels)

httpie/sessions.py — Persistent sessions
Saves cookies, auth, and headers between requests to named session files on disk.

httpie/downloads.py — wget-like file downloads
Handles streaming large responses to disk with progress reporting.

httpie/plugins/ — Plugin system
Extensible auth and formatting plugins. base.py defines the interfaces; registry.py discovers and loads them.

httpie/ssl_.py — TLS/HTTPS
Custom certificate loading, client certs, and SSL context configuration.

httpie/manager/ — The httpie management command
Handles top-level subcommands like httpie plugins install, httpie cli export-args, and update checking.

httpie/internal/ — Background daemons
Runs periodic background tasks (e.g. update availability checks) without blocking the main request.

Request Flow (simplified):

  http POST api.example.com/users name=Alice
          |
          v
    cli/argparser.py   ->  parse args, validate
          |
          v
    cli/requestitems.py ->  "name=Alice" -> JSON body
          |
          v
    client.py           ->  build & send via requests
          |
          v
    output/processing.py -> format headers + body
          |
          v
    output/writer.py    ->  colorized output to terminal

This repo is the Python implementation of HTTPie CLI, a human-friendly command-line HTTP client. Installed commands are defined in setup.cfg: http and https send requests, while httpie is a manager command mostly for plugin/CLI management.

At a high level, a request flows like this:

The console command enters through httpie/main.py, then hands off to httpie/core.py. core.raw_main() loads config defaults, installed plugins, parses arguments, handles debug/traceback modes, and wraps the program in user-friendly error handling.

CLI syntax is defined in httpie/cli/definition.py. Request items like Header:Value, name=value, field:=json, file uploads, and query params are interpreted by httpie/cli/requestitems.py.

httpie/client.py converts parsed args into a requests.Request, prepares it, applies HTTPie-specific behavior like sessions, headers, compression, SSL options, redirects, cookies, offline mode, and transport plugins. client.collect_messages() yields the prepared request and, unless offline, the response. httpie/core.py consumes those messages as a stream.

Output is rendered by httpie/output/writer.py, which chooses raw, encoded, pretty, or streaming output depending on terminal state, flags, content type, and formatting options.

Main Components:

httpie/core.py is the orchestration layer. It owns the main lifecycle: parse args, call the client, handle downloads, choose exit statuses, and write each request/response message.

httpie/cli/ is the command-line interface layer. It defines options, validates arg types, parses HTTPie's special request-item syntax, and supports nested JSON.

httpie/client.py is the HTTP execution layer. It builds requests.Session, mounts HTTP/HTTPS adapters, applies plugin transport adapters, prepares requests, follows redirects, updates sessions/cookies, and yields request/response messages.

httpie/output/ is the presentation layer. It formats headers, JSON, XML, colors, metadata, progress UI, raw streams, pretty streams, and terminal-aware output.

httpie/plugins/ provides extension points for auth, transport adapters, converters, and formatters. The plugin manager loads Python entry points and makes them available during request construction and output processing.

httpie/sessions.py, httpie/cookies.py, and httpie/config.py handle persistent state: config files, default options, stored headers/auth, and cookies.

httpie/downloads.py implements --download behavior, including resume/progress/final file writing.

httpie/manager/ backs the separate httpie command — not the request-sending path; it dispatches management tasks like plugin operations.

The clean mental model: CLI parser turns friendly shell syntax into structured args, client turns args into Requests objects and network I/O, output turns request/response messages into terminal-friendly text.

Running it locally

1. Install (one command):
   make all
   This creates a venv/, installs all dependencies with HTTPie in editable mode, and runs the test suite to confirm everything works.

2. Activate the venv:
   source venv/bin/activate

3. Use your dev copy:
   http --version
   http GET httpie.io/hello

Because it's installed in editable mode (pip install -e .), any code change you make in httpie/ is immediately reflected — no reinstall needed.

Useful make tasks:
- make test           Run the full pytest suite
- make test-cover     Tests with coverage report
- make codestyle      Check PEP8 compliance (flake8)
- make clean          Wipe venv and build artifacts

To run a single test file: python -m pytest tests/test_uploads.py

What to read first:
1. httpie/__main__.py — the actual entry point for the http/https commands
2. httpie/core.py — the request lifecycle end-to-end
3. httpie/cli/definition.py — the full CLI surface

After that, follow whichever path matches what you want to work on: httpie/client.py for HTTP behavior, httpie/output/ for formatting, httpie/sessions.py for session persistence, or httpie/plugins/ for the extension system.

The tests/ directory mirrors the source structure closely — good to read alongside the source.

For a new checkout, I'd start with the maintainer-supported path:

  make all

That creates ./venv, installs dev/test dependencies, installs HTTPie in editable mode, and runs the test suite. After that:

  source venv/bin/activate
  which http
  http --version
  http --offline pie.dev/post hello=world
  http --debug --offline pie.dev/get

You can also skip activation and run the local binary directly:

  ./venv/bin/http --version
  ./venv/bin/python -m pytest

For tests:

  make test
  make codestyle
  python -m pytest tests/test_cli.py
  python -m pytest tests/test_cli.py::some_test_name

If you want a quick orientation tour, look at these first:

- README.md for what the tool is supposed to feel like from a user's perspective.
- CONTRIBUTING.md for setup and test workflow.
- setup.cfg for dependencies and command entry points.
- httpie/main.py as the tiny process entry point.
- httpie/core.py for the main lifecycle.
- httpie/cli/definition.py for the CLI surface area.
- httpie/client.py for how requests are built and sent.
- httpie/output/writer.py for how terminal output is chosen and streamed.
- tests/test_cli.py, tests/test_httpie.py, and tests/test_output.py for executable examples of expected behavior.

Note: your working tree currently has a modified README.md, so avoid running make clean unless you're comfortable with what it removes.

Here's a complete walkthrough of the pipeline, from shell invocation to bytes on the wire.

Step 1 — Entry point
The http / https commands resolve to httpie.__main__:main, which calls core.main(). Just a clean entry and keyboard-interrupt guard.

Step 2 — Argument parsing
core.main() passes the raw sys.argv to HTTPieArgumentParser.parse_args(). After standard parsing, it runs a fixed sequence of post-processing methods:

- _apply_no_options: Handles --no-OPTION flags
- _process_request_type: Sets args.json / .form / .multipart booleans
- _guess_method: Infers GET vs POST from whether there's data
- _parse_items: Parses all key=value-style args
- _process_url: Expands bare hosts (:3000/foo -> http://localhost:3000/foo)
- _process_auth: Resolves auth from --auth, URL credentials, .netrc, or session file
- _setup_standard_streams: Redirects env.stdout -> env.stderr when --download is set

Step 3 — Parsing request items
Every bare argument after the URL (e.g. name=Alice, X-Token:abc, file@photo.jpg) is a KeyValueArg:

  ":"   X-Foo:bar       -> Header
  "=="  search==cats    -> Query param
  "="   name=Alice      -> JSON / form field
  ":="  active:=true    -> Raw JSON value
  "@"   file@photo.jpg  -> File upload

Step 4 — Building the requests kwargs
collect_messages() calls make_request_kwargs(), which translates args into a plain dict ready for requests.Request(...). Headers, body, auth, and params are all assembled here.

Step 5 — Session setup
build_requests_session() creates a requests.Session and mounts two custom adapters:
- HTTPieHTTPAdapter — plain HTTP
- HTTPieHTTPSAdapter — HTTPS with custom cipher suites, SSL version pinning, client certificates

Step 6 — Preparation and send loop (generator)

  request = requests.Request(**request_kwargs)
  prepared_request = requests_session.prepare_request(request)

  while prepared_request:
      yield prepared_request          # yield the request (for --verbose output)
      response = requests_session.send(prepared_request, **send_kwargs)
      yield response                  # yield the response
      if response.next and args.follow:
          prepared_request = response.next   # follow redirect

The generator yields both the request and response as they happen — making --verbose, --all, and streaming output work without a complex state machine.

Step 7 — Output
Back in core.program(), for each yielded object:
- OutputOptions.from_message() decides what to print based on --print
- write_message() chains formatters (JSON pretty-print, Pygments syntax highlighting)
- For --download, the response body is streamed to disk via Downloader

The two things most worth internalising: _parse_items() + RequestItems is where all the magic syntax lives, and collect_messages() being a generator is what makes the streaming/redirect/verbose output model coherent.

Here's the request lifecycle in this codebase, from shell command to network response.

1. Entry Point
The installed http and https commands both point to httpie.__main__:main. That function imports and calls httpie.core.main() from httpie/main.py. httpie.core.main() loads the parser from httpie/cli/definition.py, then calls raw_main() in httpie/core.py.

2. Global Setup
raw_main() does the outer application work:
- figures out whether the program is http or https
- decodes raw args, handles daemon mode
- loads installed plugins, prepends configured default options
- handles --debug / --traceback
- parses CLI args

3. Argument Parsing And Normalization
The CLI surface is declared in httpie/cli/definition.py. The custom parser logic lives in httpie/cli/argparser.py. It does more than plain argparse: decides request data type, handles stdin, infers GET vs POST, expands shorthand URLs, picks http:// or https://, processes output options, resolves auth, handles cert/key prompts, and parses HTTPie's request item syntax.

4. Request Items Become Structured Data
HTTPie's CLI syntax gets converted by httpie/cli/requestitems.py:

  http POST pie.dev/post X-Token:abc name=Alice active:=true q==search

becomes:
  X-Token:abc    -> request header
  name=Alice     -> string body field
  active:=true   -> JSON boolean body field
  q==search      -> URL query param

Stored on args as: args.headers, args.data, args.files, args.params, args.multipart_data.

5. Core Starts The Request Program
  messages = collect_messages(env, args=args, ...)

The design: collect_messages() yields a prepared request first, then one or more responses. core.program() just consumes "messages" and writes them.

6. Client Builds Request Kwargs
make_request_kwargs() produces:
  {
      'method': args.method.lower(),
      'url': args.url,
      'headers': headers,
      'data': prepared_body,
      'auth': args.auth,
      'params': args.params.items(),
  }

7. Headers And Body Are Finalized
Default headers always set User-Agent, JSON Accept/Content-Type for JSON requests, form Content-Type for non-file form requests. Then default headers, session headers, and CLI headers are merged. finalize_headers() trims values and encodes strings. Bodies are prepared by httpie/uploads.py.

8. Requests Session Is Built
HTTPie mounts its own adapters:
- HTTPieHTTPAdapter for http://
- HTTPieHTTPSAdapter for https://

The HTTP adapter preserves repeated headers on responses (httpie/adapters.py). The HTTPS adapter builds a custom SSL context (httpie/ssl_.py). Transport plugins can mount additional adapters.

9. Request Is Prepared
  request = requests.Request(**request_kwargs)
  prepared_request = requests_session.prepare_request(request)
  transform_headers(request, prepared_request)

transform_headers() fixes repeated headers. --path-as-is restores the original path. --compress compresses the prepared body.

10. Request Is Yielded, Then Sent
  yield prepared_request  # print in verbose/offline modes

Then:
  response = requests_session.send(request=prepared_request, **send_kwargs)

Redirects are handled manually (allow_redirects=False). If response.next and --follow, HTTPie loops. Finally:
  yield response

11. Core Writes Output And Sets Exit Status
program() loops over each yielded request/response message: decides headers/body/metadata to print, tracks initial request and final response, maps HTTP status to exit status if --check-status, and writes through the output layer.

Short version:
  shell args -> argparse normalization -> RequestItems parsing
  -> make_request_kwargs() -> requests.Request(...)
  -> Session.prepare_request() -> yield PreparedRequest
  -> Session.send() -> yield Response -> output writer

Three areas worth improving:

1. _process_auth in httpie/cli/argparser.py

The method has a "# TODO: refactor & simplify" comment. It handles four separate auth sources — URL credentials, --auth flag, .netrc, and session files — in one 70-line block with deeply nested conditionals. Credential resolution, validation, and user prompting are all tangled together.

This makes it hard to add a new auth source or write a focused test for just one path. A cleaner shape would be a prioritized resolution chain that returns an AuthCredentials object, then a separate step that validates and prompts.

2. collect_messages in httpie/client.py

The function does more than its name implies. In ~100 lines it: resolves and loads the session file, builds request kwargs, builds the requests.Session, prepares the request, sends it, follows redirects, and saves the session back to disk.

The concrete cost is testability. To test redirect handling you have to also provide a valid session setup. The program() function in httpie/core.py already has a "# TODO: Refactor and drastically simplify" comment noting this.

The natural split: request building (pure function of args), a send loop that yields messages, and session persistence as a wrapper around both.

3. Environment class-level mutable defaults in httpie/context.py

  class Environment:
      args = argparse.Namespace()   # shared across all instances
      stdin: Optional[IO] = sys.stdin
      stdout_isatty: bool = stdout.isatty()   # evaluated at import time

Two problems: args = argparse.Namespace() is a single shared object — any instance that doesn't explicitly override it mutates the same namespace. And stdout_isatty is evaluated at import time, not at instance creation. In tests or embedded use where stdout is redirected after import, instances silently get the wrong value.

Fix: move stream defaults into __init__ with lazy evaluation.

Here are the 3 areas I'd flag first.

1. Split Up Argument Parsing Side Effects

httpie/cli/argparser.py does a lot after argparse: it mutates env, rewrites streams, infers method, parses request items, normalizes URLs, resolves auth, reads stdin/raw input, handles cert prompts, and validates incompatible options.

That makes it hard for a new contributor to know whether something belongs in parsing, request construction, or runtime execution. A useful improvement would be introducing a smaller immutable "request spec" object after parsing, so later code does not depend on a giant mutable argparse.Namespace.

2. Simplify core.program() Output/Download Control Flow

httpie/core.py is the central loop for request/response messages, output separators, streamed uploads, status handling, and downloads. The code itself calls this out with a comment.

Output formatting decisions, download lifecycle, request body echoing, and exit status updates are interleaved in one loop — increasing regression risk around edge cases like --download, --verbose, streamed uploads, redirects, and non-TTY output. I'd extract message rendering/separator decisions into a small output coordinator.

3. Make Request Execution Stages More Explicit

collect_messages() in httpie/client.py is elegant, but dense. It handles sessions, kwargs construction, session construction, auth persistence, request preparation, path/compression tweaks, offline mode, sending, redirect following, cookie updates, and session saving.

The generator shape is good, but the function mixes several phases that could be named and tested independently: "load session state," "prepare request," "send with redirect policy," and "persist session state." This would make bugs around redirects, sessions, cookies, and plugins easier to isolate.

If I were contributing, I'd start with area 1 or 2 before touching request execution — more structural, and likely to make future behavior fixes less nerve-wracking.

How it's tested

The http() test helper is the foundation. It calls core.main() directly — no subprocess — captures stdout/stderr into temp files, and returns a StrCLIResponse (a str subclass with .json, .exit_status, .stderr attributes).

Real HTTP via pytest-httpbin: The httpbin / httpbin_both / httpbin_secure fixtures spin up a local httpbin server, so the full stack is exercised on every test run.

--offline for fast/networkless tests: test_offline.py tests request construction (method inference, body encoding, headers) without touching the network.

Doctests: pytest.ini includes --doctest-modules.

MockEnvironment subclasses Environment with temp files for stdout/stderr and a fresh temp config dir per test.

The structural trade-off: almost entirely integration tests. Great for catching regressions, but it means slow tests, hard-to-isolate failures, and edge cases in internal functions only reachable indirectly.

Specific coverage gaps:

1. _process_auth resolution logic
The method resolves four auth sources but priority rules — which source wins when multiple are present — aren't explicitly tested for all combinations. A parse_args-level unit test is the right shape: call parser.parse_args(args=[...], env=MockEnvironment()) and assert on args.auth. No network needed.

2. Environment shared class-level state
No tests verify two Environment instances are isolated from each other:
  def test_environment_instances_do_not_share_args():
      e1, e2 = Environment(), Environment()
      e1.args.foo = 'bar'
      assert not hasattr(e2.args, 'foo')  # currently fails

3. collect_messages redirect and session-persistence paths
The redirect loop and session save are only tested end-to-end. Extracting session persistence would make it directly testable.

4. Error paths in core.raw_main
DNS failure and connection error handlers have distinct user-facing messages but no tests assert on these specific messages.

This project is tested with a pretty mature pytest suite. The tests are mostly behavior-level: they invoke HTTPie through test helpers that call httpie.core.main() with a fake Environment, capture stdout/stderr/devnull, and assert on output, JSON bodies, exit status, headers, cookies, etc.

The core test helper is http() in tests/utils/__init__.py. It builds CLI args, runs core.main(), captures streams from MockEnvironment, and returns a response-like object with .stderr, .exit_status, .json, and string output.

MockEnvironment subclasses Environment — letting tests simulate TTY/non-TTY output, stdin, config dirs, stdout, stderr, and platform behavior without spawning a real process.

Network behavior is covered in a few ways:
- pytest-httpbin fixtures for common HTTP endpoints.
- A custom local HTTP server in tests/utils/http_server.py for cases httpbin cannot model cleanly.
- Some tests use remote pie.dev only when DNS is available; otherwise they skip.

Coverage is broad: CLI parsing, output, sessions, uploads, SSL, redirects, cookies, downloads, auth, defaults, JSON/XML, binary output, compression, plugins, and regressions all have dedicated files.

How I'd improve coverage:

1. Expand output matrix tests
tests/test_tokens.py explicitly says more scenarios are needed: terminal vs redirected stdout, all --print=HBhb combinations, multipart, and streamed uploads.

2. Add more focused parser normalization tests
I'd add table-driven tests for combinations like stdin plus request items, https program name plus default schemes, auth in URL plus --auth-type, and ambiguous method-vs-URL cases.

3. Strengthen session/plugin interaction tests
There's already a TODO in tests/test_auth_plugins.py to run auth plugin tests in session mode too. client.collect_messages() mixes session header/cookie/auth persistence with request preparation — bugs there can be subtle.

4. Turn skipped/xfail cases into tracked coverage goals
Known gaps: unimplemented host-header unset test, CI-skipped plugin CLI behavior, redirect xfail, JSON/compression FIXMEs. Triage into "expected unsupported behavior" or "coverage debt."

5. Add smaller unit tests around request construction
Functions like make_request_kwargs(), make_default_headers(), prepare_request_body(), and transform_headers() would benefit from more direct tests around edge cases: repeated headers, Content-Length, chunked body callbacks, multipart boundaries, offline mode.