Accept-Encoding

Technique Definition

Accept-Encoding lets the client constrain which content codings are acceptable in the response. Under Existence Oracle analysis, it can sometimes elicit 406 vs 404, but only when the request makes every viable coding unacceptable and the server refuses fallback.

Primary Headers / Methods

Request Header

• Accept-Encoding

Representation Dimension It Relies On

• Content coding

Primary Method Context

• GET
• HEAD

Secondary Method Context

• Any method whose response content is subject to content-coding negotiation

Can Elicit

Primary Differential

• 406 vs 404 in a narrow branch where no acceptable coding remains

Secondary / Adjacent Outcomes

• 200 vs 404 if the server sends the response without content coding
• 200 vs 404 if the server ignores the header or chooses an acceptable coding

Stage Role

Under this taxonomy, Accept-Encoding is a tertiary trigger for the 406 vs 404 differential.

Best Use

Accept-Encoding is best used only when the target is known to negotiate content codings and the probe explicitly closes off identity fallback.

The cleanest probing form is a request that makes all relevant codings unacceptable, including identity.

Examples:

• Accept-Encoding: gzip;q=0, br;q=0, identity;q=0
• Accept-Encoding: *;q=0, identity;q=0

These are useful only if the server actually honors the field and actually needs a coding choice to answer.

Why It Works as an Existence Trigger

A 406 response means the server treated the target as a resource with candidate response representations, considered their content codings, found no acceptable coding under the received Accept-Encoding field, and declined fallback. A nonexistent target can terminate earlier at 404.

Method Applicability

GET

• Primary method context.
• Cleanest setting for response coding negotiation.

HEAD

• Also primary.
• Useful when coding-related response semantics are still visible in headers.

Other Methods

• Valid in principle where the response body is still negotiable.
• Rarely the clearest oracle setting.

Trigger Strength / Normative Level

Weak Normative Core

RFC 9110 clearly includes Accept-Encoding in proactive negotiation, but it also leaves room for the server to send a response without content coding when that remains acceptable.

Practical Result

This technique is structurally valid but weak as a canonical oracle trigger. In many cases it collapses to success rather than 406.

Portability Notes

• The probe fails if identity remains acceptable.
• The probe is weak against endpoints that never compress that representation in the first place.
• Intermediary decompression or recompression can blur the signal in deployment, though that belongs to Stage 3 analysis.
• This is not a strong first-choice elicitation technique.

Detection Notes

1. Establish a known-existing target and a known-nonexistent target.
2. Send the same request to both.
3. Add only one manipulator: an Accept-Encoding value that makes every relevant coding unacceptable, including identity.
4. Compare outcomes.
5. A 406 on the existing target and 404 on the nonexistent target confirms a coding-based existence trigger.

Relationship to Other Techniques

Versus Accept

• Accept is the clean canonical trigger.
• Accept-Encoding is much easier for a server to defeat via identity fallback.

Versus Accept-Language

• Accept-Language varies meaning.
• Accept-Encoding varies wire-level coding.
• Both can elicit 406, but Accept-Encoding is often the weaker probe.

Scope & Limitations

• It does not prove that the resource has multiple semantic representations.
• It does not prove that compression is normally used.
• It does not prove anything about cache state or intermediary behavior.
• It only proves that content-coding negotiation reached an existing target and failed strictly enough to yield 406.