Method handling
Servers that lie about which HTTP methods they support, or violate RFC 9110 method-response rules.
An endpoint that claims (via Allow or OPTIONS) to support GET/POST/PUT/PATCH/DELETE/OPTIONS but only actually handles GET. The chaos varies by mode: lying Allow header, silent success on wrong method, 405 without Allow, or OPTIONS that contradicts reality.
mode
lying-allow (default; Allow header claims six methods, only GET works), silent-on-wrong-method (non-GET returns 200 with empty body — looks like success), 405-without-allow (405 with no Allow header, violates RFC 9110), options-mismatch (OPTIONS advertises six methods; real handler accepts only GET).
Most HTTP clients trust the server’s method advertisements. The Allow
header on a 405 says “these are the methods you can use.” OPTIONS
returns the same information for CORS preflights and capability probes.
RFC 9110 specifies how these should behave; not every server agrees.
These modes test what your client does when the metadata lies.
- lying-allow is the most common real-world bug: the Allow header is hardcoded across all responses and doesn’t reflect what each method actually returns.
- silent-on-wrong-method is rarer but more dangerous — your DELETE appears to succeed (200), so your code marks the resource deleted even though the server ignored the request.
- 405-without-allow is an RFC violation that strict validators catch but most clients let pass.
- options-mismatch exposes a class of CORS preflight bugs: cross-origin clients ask OPTIONS what’s allowed, get one answer, then fail on the actual request.