Summary

  • RFC 9110 defines Max-Forwards as a decimal count of remaining proxy forwards for TRACE and OPTIONS. At zero, the receiving intermediary answers as the final recipient for that request.
  • The count measures compliant forwarding acts, not companies, trust zones or legal authority. Via and Proxy-Status may add evidence, but both preserve disclosure choices.
  • A defensible diagnostic record binds the method, target, starting count, observation time, responder evidence and response digest. It never treats the numeral as permission to inspect a network.

A counter with one job

An HTTP request can pass through several actors before reaching an origin: a local gateway, a corporate proxy, an edge service, a reverse proxy and perhaps another intermediary hidden behind the public boundary. When something fails or loops, the operator needs a way to ask what an earlier recipient sees. A complete, centrally maintained map would be expensive, stale and often inappropriate to disclose. Max-Forwards solves a much smaller problem.

RFC 9110 gives the field meaning only with TRACE and OPTIONS. Its value is a decimal integer representing the remaining number of times the request may be forwarded. Every intermediary receiving one of those methods with the field must inspect it before forwarding. If it receives zero, it must not forward and must answer as the final recipient. If the value is positive, the forwarded value becomes the smaller of one less than the received count and the intermediary’s own supported maximum.

This arithmetic creates a temporary stopping point. It does not create an organizational fact. A single company can operate several forwarding components. Several companies can appear behind one managed edge. A service mesh may add recipients inside one administrative domain, while routing changes can remove them on the next request. The counter advances when protocol forwarding occurs, not when a contract, corporate boundary or security clearance changes.

The distinction matters at zero. “Respond as the final recipient” means final for this diagnostic request at this depth. It does not mean “I am the origin,” “I own the target,” or “I speak for every system behind me.” A monitoring product that labels the zero responder as the authoritative backend has already converted a procedural stop into a claim RFC 9110 never makes.

OPTIONS and TRACE answer different questions

OPTIONS asks about communication options at a target resource or at a server. Its semantics explicitly avoid implying a resource action. With an asterisk target it addresses the server generally; with an ordinary target it concerns communication with that resource. A client can add Max-Forwards to direct the inquiry to a selected recipient in the chain. The proxy is not allowed to invent the field while forwarding an OPTIONS request that arrived without it.

The response still has a local shape. RFC 9110 recommends fields that expose applicable optional features, but it defines no universal OPTIONS document. One intermediary might report only a small set of capabilities. Another might require authentication before exposing diagnostic detail. A third might disable useful extensions. The counter determines where forwarding stops, not what that recipient is required to reveal or what a client is entitled to do next.

TRACE is more sensitive. It requests an application-level loopback of the received request message. This helps reveal transformations and, especially, the Via chain. Yet the method carries explicit constraints: the client must not send sensitive fields that could be reflected, the final recipient should remove likely sensitive material, the request cannot carry content and the response cannot be cached.

Those rules defeat a tempting interpretation of Max-Forwards as a right of inspection. A client may be able to address a TRACE request to an intermediate depth and still receive a refusal, a filtered reflection or no operationally useful identity. Local policy can disable the method or restrict it. Even when the response succeeds, the reflected message is an observation from that request, not a continuing mandate to interrogate infrastructure.

Why a hop is not a company

Via supplies evidence that Max-Forwards intentionally omits. It records intermediate protocols and recipients and can help find loops or understand protocol capabilities. But Via itself is not a corporate register. A received-by value may be a pseudonym when a real host is sensitive. Comments are optional and can be removed. Several members can be combined under limited conditions, including common organizational control and compatible protocol values.

Those options are not defects. They acknowledge that interoperability and exposure are different decisions. The minimum protocol needs enough information to forward correctly and diagnose bounded failures. It does not need a universal public inventory of internal machines. The same institution might disclose detailed Via data to authenticated operators and pseudonyms to the open Internet without changing Max-Forwards semantics.

RFC 9209’s Proxy-Status field can enrich a response with information about how intermediaries handled it, including errors, next hops, received status and implementation details. Its list order can represent intermediaries from the origin side toward the user agent. That is stronger evidence for a particular response, but it is still elective evidence. Intermediaries decide when to add the field and can remove earlier members to prevent internal information from leaking. Origin servers must not generate it.

The security reason is plain: backend topology and configuration can help an attacker target services that were never designed for hostile direct traffic. Some details may be suitable only for authorized parties. Therefore a missing Proxy-Status member does not prove a missing hop, and a present member does not automatically prove the operator’s legal identity. It is a protocol assertion whose trust depends on transport, message integrity and local relationships.

The path has a timestamp

A diagnostic chain is not necessarily durable. Load balancers choose different backends, edge networks change routing, service meshes alter sidecars and failover moves traffic. Two requests with the same target and Max-Forwards value can stop at different recipients. Even on one connection, HTTP does not generally let a server assume that separate requests belong to the same user agent unless the connection is both secured and specific to that agent.

The practical unit of evidence is therefore an observation, not a topology row. Record the target URI, method, initial Max-Forwards value, time, transport context, status, selected response fields and a digest of the response. If Via or Proxy-Status is present, preserve it exactly with its disclosure context. If a retry produces a different responder, do not overwrite the first record; compare the two observations.

The response’s non-cacheability reinforces this design. OPTIONS and TRACE results are not reusable cache objects under RFC 9110. A dashboard may retain them as audit evidence, but it should not present an old result as a fresh protocol answer. Archival for accountability and cache reuse for request satisfaction are different functions.

A valid HTTP Message Signature can protect selected covered components against undetected modification within an application profile. That helps answer whether a particular field arrived intact from a recognized signer. It does not answer whether the signer owns a corporate hop, whether an omitted intermediary exists, whether TRACE disclosure was authorized or whether a later path will be the same. Integrity narrows uncertainty; it does not convert a count into authority.

A safer diagnostic workflow

Start with the question, not the mechanism. If the objective is to locate a loop, use a bounded series of TRACE or OPTIONS observations only where local policy permits. Increase Max-Forwards deliberately and stop when the evidence explains the fault. Do not run an open-ended scanner merely because the field accepts a larger integer.

Separate three ledgers. The protocol ledger records how the request was forwarded and where it stopped. The identity ledger records which operator or service is believed to control the responder, with independent evidence and an expiry time. The authorization ledger records who approved the diagnostic, which fields may be exposed, the permitted target and the observation window. Max-Forwards belongs only in the first ledger.

Treat discrepancies as information. A counter decrement without the expected Via member may reflect permitted pseudonymization, aggregation, transformation or a nonconforming intermediary; it is not enough by itself to accuse an operator. A new Proxy-Status member may reflect a routing change rather than a new company. An OPTIONS result that differs across depths can reveal policy layering without proving that one layer can authorize another.

Finally, minimize the request. TRACE must not carry credentials, cookies or sensitive fields. OPTIONS content has no use defined by RFC 9110 even though content can be syntactically present with an appropriate media type. Diagnostics should not turn a routing problem into an information-disclosure event.

Sources