Request Minimizer

Most debugging questions are answered and forgotten. This one kept coming back: the request worked with a tiny cookie set, but every fresh copy from the browser brought the whole stack along. I wanted a repeatable way to find the smallest working set instead of re-deriving it by trial and error.

The tool does exactly one thing: import a copied cURL request, verify the endpoint, experimentally reduce the cookie set, and fetch with the verified result. Version 0.1 minimizes cookies only. It is not browser automation, a login tool, a credential scraper, a proxy, a server, or a general-purpose HTTP framework.

Every unnecessary cookie replayed is additional credential exposure. A copied browser request can carry session tokens and tracking material the endpoint never reads — but a server that receives them has them.

A successful HTTP status is not proof of success either. Login HTML, redirects, internal provider errors, and unexpected JSON can all arrive inside an HTTP 200 response. The tool only treats a request as successful when a provider-specific validator confirms meaningful response evidence; unknown response shapes fail closed.

The safety rules the tool never bends:

• +Never print cookie values, tokens, raw response bodies, request IDs, trace IDs, or arbitrary provider JSON
• +Never replay to another host, scheme, or effective port — the imported endpoint is locked
• +Do not follow redirects, and disable environment proxies
• +Use bounded request counts and delays — every request counts toward the budget
• +Treat session expiration and provider response-shape changes explicitly
• +Keep enough checkpoint state to resume a run without ever storing cookie values in the checkpoint
• +Fail closed rather than guess

The choices that keep the experiment narrow and trustworthy:

1. 01

   Split non-secret request structure from secret-bearing local values

   The replayable request shape lives in a config file; cookie values and sensitive headers live in a restricted local secret store with restrictive file permissions.

2. 02

   Provider-specific validators with explicit allowlists

   A validator defines what success means for one endpoint contract and returns only explicitly approved summary fields — never raw provider data.

3. 03

   Fresh full-set baseline before reduction

   Every run starts by confirming the complete imported set still works against the current server state.

4. 04

   Confirm successful candidates; re-check the known-good set after authentication-looking failures

   Successful candidates need two fresh confirmations by default, and a known-good control request distinguishes a removed cookie from session expiration.

5. 05

   Final one-cookie cleanup and fresh uncached verification

   After the main reduction, retained cookies are tested one at a time, and the final set gets a fresh verification before any result is written.

6. 06

   Bind minimized results to imported-request provenance

   Results carry a secret-free configuration fingerprint; fetch refuses stale, incomplete, failed, or mismatched results.

7. 07

   Keep human and JSON output deliberately small and safe

   Progress shows cookie names and counts only; JSON mode prints one safe document with validator-approved summary fields.

The key realization was that “the request returned HTTP 200” could not be the success condition. Early versions treated the transport status as the answer; the Alibaba validator work changed that.

The validator had to distinguish real nested success evidence from login pages, redirects, malformed JSON, internal failures carried inside HTTP 200 responses, missing usage fields, and unknown response shapes. None of those can be called success, and several of them look exactly like success at the transport layer.

That is the moment the project changed from a cookie-removal script into a trustworthy tool with an explicit response contract: a request only counts as working when the provider's actual response proves it.

The first published end-to-end result in the README: an authenticated Alibaba Model Studio Token Plan usage request reduced from 45 cookies to 1 cookie in 18 requests, roughly 1 minute 23 seconds.

The approved capture on this page shows a separate, current run: a 41-cookie baseline reduced to one required cookie after 15 verification requests. These are two runs, not one number rewritten to match a screenshot.

Both runs retained the same cookie name — login_aliyunid_ticket — and its value was never displayed. Both results are scoped to a specific endpoint, region, account session, and moment in time; providers can change authentication requirements, and a surviving cookie value is still a credential that must be treated like a password.

The proof behind this case file:

• FIG.

  Real Alibaba token-plan request: 41 cookies reduced to one required cookie

  The approved terminal capture from a real Alibaba token-plan run: a 41-cookie baseline reduced to one required cookie after 15 requests, with a passed final verification.

• REPO
  Request Minimizer repository↗

  The README documents the safety model, the workflow, the validator checklist, and the limitations.

The repository runs pytest, Ruff, mypy, and package builds in CI across Python 3.12, 3.13, and 3.14. Tests use fake transports and synthetic credentials — automated tests never contact a real provider.

The failure classes that matter are covered explicitly: parser rejection of dangerous shell forms, redaction and secret-nondisclosure, fail-closed validation of unknown response shapes, provenance checks, and replay safety. The same guarantees are exercised through the CLI boundaries, not just helper functions.

Releases are built and verified before publishing, so the package a user installs matches what CI validated.

Version 0.1 is deliberately narrow: it minimizes cookies only, for one imported request at a time. That narrowness is the safety model — every additional capability would add a new way to leak or guess.

Next direction

• →Add or maintain validators only when a real endpoint has a distinct meaningful response contract, preserving fail-closed behavior and the project's narrow safety model. No generalized authentication minimization.