RFC Standards
The HTTP specifications that define oracle-producing behavior. RFC compliance is the source of oracles, not a defect in server implementations.
HTTP oracles don't require broken servers. They are a direct consequence of servers implementing HTTP specifications correctly.
When a server returns 403 Forbidden for an existing resource but 404 Not Found for a nonexistent one, it is following RFC 9110 §15.5.4 and §15.5.5 exactly as written. When it includes distinct WWW-Authenticate error parameters for an expired token versus an invalid signature, it is following RFC 6750 §3.1 as written. When it returns 422 Unprocessable Content for a PATCH against an existing resource but 404 for a nonexistent one, it is following RFC 5789 §2 as written.
Each of these is a correct response. Each is also a differential signal.
Why RFC compliance matters
The HTTP specifications define response end states — status codes, required headers, mandatory fields — but leave evaluation order and conditions to the implementation. A server that resolves the target resource before evaluating authorization constraints will produce different status codes depending on whether the resource exists. A server that validates request content against the existing resource's schema before returning 422 reveals that the resource was found and typed. A server that enforces the Allow header on 405 Method Not Allowed responses confirms which methods are registered for that URI.
These behaviors are not bugs. They are the natural output of correct RFC implementations. parlov treats them as the authoritative source of oracle signals, not as anomalies to explain away.
Key specifications
| RFC | Title | Oracle relevance |
|---|---|---|
| RFC 9110 | HTTP Semantics | All method definitions, status code classes, conditional requests, content negotiation |
| RFC 7235 | HTTP Authentication | 401 semantics, WWW-Authenticate header requirements |
| RFC 6750 | Bearer Token Usage | WWW-Authenticate error parameter granularity for token validation oracles |
| RFC 5789 | PATCH Method | 422/404 existence differential, atomicity requirements |
| RFC 6585 | Additional HTTP Status Codes | 429 Too Many Requests with Retry-After |
| RFC 9111 | HTTP Caching | Cache-Control, 304 Not Modified, conditional request mechanics |
This section
GET
RFC 9110 §9.3.1. Primary retrieval method. The canonical source of 403/404 and 200/404 existence differentials. Safe and cacheable.
HEAD
RFC 9110 §9.3.2. Identical to GET without response content. Bandwidth-efficient enumeration. Status codes mirror GET semantics per spec.
POST
RFC 9110 §9.3.3. Creation and processing. 409/2xx existence differential. Redirect behavior on existing resource matches.
PUT
RFC 9110 §9.3.4. Full replacement semantics. 422/404 and 422/201 differentials. Idempotent, non-cacheable.
PATCH
RFC 5789 §2. Partial modification. 422/404 existence differential. Atomicity requirement. Neither safe nor idempotent.
DELETE
RFC 9110 §9.3.5. Deletion semantics. 405/404 existence differential. Applicable primarily in authoring contexts.
OPTIONS
RFC 9110 §9.3.7. Capability discovery. Allow header presence differential. Not cacheable.
1xx Informational
RFC 9110 §15.2. Interim responses signaling connection status or request progress. Not an oracle source directly but relevant to probe pipeline behavior.
2xx Successful
RFC 9110 §15.3. The full range of success codes — 200, 201, 202, 204, 206 — and their oracle context as baseline confirmation signals.
3xx Redirection
RFC 9110 §15.4. Redirect semantics including 303 as POST oracle signal, 304 as conditional-GET existence confirmation, and method-change rules.
4xx Client Error
RFC 9110 §15.5. The primary oracle signal space: 401, 403, 404, 405, 409, 410, 412, 416, 422, and 429 — each with distinct existence and auth context semantics.
5xx Server Error
RFC 9110 §15.6. Server error class. 500 as a probe-noise source, 501 and 503 as infrastructure signals. Probing implications and false-positive risk.