parlov docs

Accept

Accept lets the client constrain which media types are acceptable in the response — the cleanest proactive-negotiation technique for eliciting 406 vs 404.

Implemented

Technique Definition

Accept lets the client constrain which media types are acceptable in the response. Under Existence Oracle analysis, it is the cleanest proactive-negotiation technique for eliciting 406 vs 404 because it directly asks whether the target resource has any current representation in a media type the client is willing to receive.

Primary Headers / Methods

Request Header

  • Accept

Representation Dimension It Relies On

  • Media type

Primary Method Context

  • GET
  • HEAD

Secondary Method Context

  • Any method whose response content is subject to proactive negotiation

Can Elicit

Primary Differential

  • 406 vs 404

Secondary / Adjacent Outcomes

  • 200 vs 404 if the server disregards the header and sends a default representation
  • 3xx/4xx/5xx vs 404 where other semantics dominate before negotiation becomes visible

Stage Role

Under this taxonomy, Accept is the canonical trigger for the 406 vs 404 differential.

Best Use

Accept is best used when the goal is to force the server to answer a narrow question:

Does this target have any current representation in a media type I accept, and will the server refuse fallback if the answer is no?

The cleanest probing form is an intentionally unsatisfiable media-type constraint with no wildcard fallback.

Examples:

  • Accept: application/x.parlov-does-not-exist
  • Accept: application/json;q=1, */*;q=0 against a target that is known not to offer JSON

Why It Works as an Existence Trigger

A 406 response means the server reasoned about the target resource's available response representations and concluded that none were acceptable under the received Accept field, while also declining to send a default representation. A nonexistent target can bottom out earlier at 404 Not Found.

Method Applicability

GET

  • Primary method context.
  • Cleanest and most intuitive negotiation path.

HEAD

  • Also primary.
  • Useful when the server exposes negotiation semantics without sending a response body.

Other Methods

  • Still valid in principle.
  • Weaker as an oracle trigger because response-generation semantics can be dominated by method-specific processing.

Trigger Strength / Normative Level

Moderate Normative Core

RFC 9110 clearly allows Accept to participate in proactive negotiation and clearly defines what 406 means.

However, the RFC does not require the server to honor the header in every case. The server can choose a default representation instead of returning 406.

Practical Result

Accept has the strongest and cleanest relationship to 406 vs 404, but the trigger is permissive rather than mandatory.

Portability Notes

  • Best portability comes from highly specific media-type requests with no wildcard escape hatch.
  • The presence of */* or other broad fallbacks weakens the probe.
  • Many real systems ignore narrow Accept constraints and still send a default HTML or JSON response.
  • This technique proves negotiation evaluation, not cache presence.

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 value designed to be unsatisfiable for the known-existing target.
  4. Compare outcomes.
  5. A 406 on the existing target and 404 on the nonexistent target is the cleanest confirmation for this technique.

Relationship to Other Techniques

Versus Accept-Language

  • Accept is the cleaner canonical trigger.
  • Accept-Language has a similar shape, but the RFC leans harder toward fallback.

Versus Accept-Encoding

  • Accept reasons about representation type.
  • Accept-Encoding reasons about content coding and is often defeated by identity fallback.

Versus Accept-Charset

  • Accept is current and common.
  • Accept-Charset is deprecated and weak for oracle work.

Scope & Limitations

  • It does not prove that the target has a selected representation.
  • It does not prove that the server supports content negotiation generally.
  • It does not prove anything about caches, validator state, or range semantics.
  • It only proves that the server treated media-type negotiation as relevant to an existing target.

On this page