Accept-Language

Technique Definition

Accept-Language lets the client express preferred natural languages for the response. Under Existence Oracle analysis, it can elicit 406 vs 404 when the server honors language negotiation strictly enough to refuse fallback rather than send a default-language representation.

Primary Headers / Methods

Request Header

• Accept-Language

Representation Dimension It Relies On

• Natural language / language tag

Primary Method Context

• GET
• HEAD

Secondary Method Context

• Any method whose response content varies by language

Can Elicit

Primary Differential

• 406 vs 404

Secondary / Adjacent Outcomes

• 200 vs 404 if the server disregards the language preference and serves a default language
• Redirects or variant selection flows where the application externalizes language choice instead of returning 406

Stage Role

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

Best Use

Accept-Language is best used when the target is known or strongly suspected to vary by language and the goal is to test whether unsupported-language requests expose existence through strict negotiation failure.

The cleanest probing form is a narrow language request with no broad wildcard fallback.

Examples:

• Accept-Language: fr-CA against a target believed to offer only English
• Accept-Language: tlh against a target unlikely to provide Klingon content

Why It Works as an Existence Trigger

A 406 response means the server treated the target as a resource with language-varying response representations, evaluated the received language preferences, found no acceptable match, and declined to send a default-language response. A nonexistent target can terminate earlier at 404.

Method Applicability

GET

• Primary method context.
• Cleanest use case for language-varying representations.

HEAD

• Also primary.
• Useful when testing whether language negotiation semantics remain visible without transferring the body.

Other Methods

• Valid in principle where the response content itself is language-negotiated.
• Much less likely to be a stable oracle in practice.

Trigger Strength / Normative Level

Weak-to-Moderate Normative Core

RFC 9110 clearly places Accept-Language inside proactive negotiation and clearly permits 406.

However, the RFC also signals that falling back to some usable representation is often the better choice.

Practical Result

This is a real technique, but weaker than Accept as a canonical probe because many servers ignore the constraint and return a default language.

Portability Notes

• Best portability comes from targets that actually publish language variants.
• This technique is weak against endpoints that do not meaningfully vary by language.
• Many deployments prefer default-language success over 406, even when the requested language is unsupported.
• Locale redirects, user-profile settings, and cookies can obscure the RFC-defined signal.

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-Language value that should be unsatisfiable for the existing target.
4. Compare outcomes.
5. A 406 on the existing target and 404 on the nonexistent target confirms that strict language negotiation can act as an existence trigger.

Relationship to Other Techniques

Versus Accept

• Accept is the cleaner canonical trigger.
• Accept-Language is similar but more often ignored for usability reasons.

Versus Accept-Encoding

• Accept-Language varies semantic content.
• Accept-Encoding varies content coding and is often defeated by identity fallback.

Scope & Limitations

• It does not prove that multiple language variants exist.
• It does not prove that language was the only selection dimension considered.
• It does not prove that the target would be retrievable in any particular default language.
• It only proves that language negotiation reached an existing target strongly enough to fail with 406.