RFC Compliance as the Source

An HTTP oracle is any server behavior that reveals protected internal state to an observer who shouldn't have access to it.

Oracles don't require broken servers. They emerge from correct implementations of HTTP specifications — RFC 9110, RFC 6585, RFC 6750, RFC 5789, and others. When a server returns 403 Forbidden for an existing resource but 404 Not Found for a nonexistent one, it's implementing RFC 9110 §15.5.4 exactly as written. When it returns 304 Not Modified for a conditional request against a resource that exists but 404 when it doesn't, that's RFC 9110 §15.4.5 working as designed. When it includes distinct WWW-Authenticate parameters for an expired token versus an invalid signature, that's RFC 6750 behaving correctly.

Each of these is a correct response. Each is also a signal.

The core insight is structural: HTTP specifications define end states (status codes, required headers, response semantics) but leave evaluation order to the implementation. When a server resolves the target resource before evaluating constraints — authentication, content negotiation, preconditions, rate limits — it creates a fork in its response pipeline. Existing resources reach the constraint check and return one status code. Nonexistent resources short-circuit to 404 before the constraint is ever evaluated. The differential between these two paths is the oracle.

parlov doesn't craft exploits or send malicious payloads. It sends ordinary, spec-compliant HTTP requests and observes how the server responds correctly. The methodology is Pavlovian: controlled stimuli, observation of normal responses, differential analysis, classification.