Accept-Charset

Technique Definition

Accept-Charset lets the client express which character encodings are acceptable in a textual response. Under Existence Oracle analysis, it is a structurally valid but weak technique for eliciting 406 vs 404 because RFC 9110 still includes it in proactive negotiation while also marking it deprecated.

Primary Headers / Methods

Request Header

• Accept-Charset

Representation Dimension It Relies On

• Charset / character encoding

Primary Method Context

• GET
• HEAD

Secondary Method Context

• Any method whose response content is textual and charset-negotiated

Can Elicit

Primary Differential

• 406 vs 404 through the general proactive-negotiation model

Secondary / Adjacent Outcomes

• 200 vs 404 if the server ignores the field and sends its default charset
• 200 vs 404 if the server can transcode or otherwise satisfy the request

Stage Role

Under this taxonomy, Accept-Charset is a weak trigger adjacent to the 406 vs 404 differential.

Best Use

Accept-Charset is best treated as a legacy or lab-oriented probe rather than a front-line elicitation technique.

The cleanest probing form is a narrow charset request with no wildcard fallback against a target believed to emit text in a different charset.

Examples:

• Accept-Charset: iso-8859-5
• Accept-Charset: utf-16;q=1, *;q=0 against a target believed to emit UTF-8 only

Why It Works as an Existence Trigger

A 406 response means the server treated the target as a resource with response representations whose textual encoding mattered, evaluated those encodings against the received Accept-Charset field, found no acceptable match, and declined fallback. A nonexistent target can terminate earlier at 404.

Method Applicability

GET

• Primary method context.
• Most sensible place for charset-varying textual representations.

HEAD

• Also primary.
• Useful when charset selection is reflected in metadata without transferring the body.

Other Methods

• Valid in principle where the response content is still textual and negotiable.
• Rarely the clearest oracle setting.

Trigger Strength / Normative Level

Weak Normative Core

RFC 9110 still includes Accept-Charset in proactive negotiation, so a 406 path is semantically available.

But the field is explicitly deprecated, and the RFC does not treat it as a favored or especially important modern mechanism.

Practical Result

This is a valid page mostly for completeness. It is not a strong canonical trigger.

Portability Notes

• Most general-purpose user agents do not send Accept-Charset.
• Many servers ignore it entirely.
• Modern UTF-8 defaults make strict charset negotiation uncommon.
• This technique is therefore weak both semantically and operationally.

Detection Notes

1. Establish a known-existing textual target and a known-nonexistent target.
2. Send the same request to both.
3. Add only one manipulator: an Accept-Charset 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 a charset-based existence trigger.

Relationship to Other Techniques

Versus Accept

• Accept is current, common, and canonical.
• Accept-Charset is deprecated and mostly completeness-driven.

Versus Accept-Language

• Accept-Language remains common in real deployments.
• Accept-Charset is usually a much weaker probe.

Scope & Limitations

• It does not prove that the target has multiple text encodings available.
• It does not prove that the server supports modern charset negotiation in any meaningful way.
• It does not prove anything about cache state or representation freshness.
• It only proves that charset negotiation reached an existing target and failed strictly enough to yield 406.