HTTP J. de Valk Internet-Draft Emilia Capital Intended status: Informational 19 July 2026 Expires: 20 January 2027 The Redirect-By HTTP Response Header Field draft-devalk-redirect-by-00 Abstract This document defines the Redirect-By HTTP response header field. It allows the software component whose decision determined an HTTP redirect to identify itself, so that an operator diagnosing a redirect can determine which component was responsible for it. The field succeeds the widely deployed, non-standard X-Redirect-By header, which this document deprecates. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 20 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. de Valk Expires 20 January 2027 [Page 1] Internet-Draft Redirect-By July 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. The Redirect-By Field . . . . . . . . . . . . . . . . . . . . 3 3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Multiple Redirects and Intermediaries . . . . . . . . . . 4 4. Relationship to X-Redirect-By . . . . . . . . . . . . . . . . 5 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 5 5.1. A Structured Field . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction An HTTP request for a given URL is frequently redirected by one of several independent components before it reaches an origin resource: a Content Delivery Network (CDN) edge rule, a reverse proxy, a load balancer, a Content Management System (CMS), or an application plugin may each issue a redirect. When such a redirect is misconfigured, an operator inspecting the response sees only the status code and the Location field (Section 10.2.2 of [RFC9110]). Neither identifies which component in the chain produced the redirect. Diagnosis then proceeds by disabling components one at a time until the responsible one is found, which is slow and error prone. This document defines the Redirect-By response header field, whose value names the software component whose decision determined the redirect. Its presence turns an opaque redirect into a self- describing one: the responsible component is named in the response itself. de Valk Expires 20 January 2027 [Page 2] Internet-Draft Redirect-By July 2026 The convention is widely deployed under the non-standard name X- Redirect-By. Since version 5.1, WordPress core has, by default, emitted X-Redirect-By on every redirect generated through wp_redirect(); wp_safe_redirect() delegates to that function. WordPress exposes the value through a filter so that themes and plugins can identify themselves [WP-X-REDIRECT-BY]. TYPO3 emits the field from its redirect and shortcut-handling middleware [TYPO3-REDIRECTS]. This demonstrates deployment across multiple independent implementations and a large installed base; this document does not attempt to quantify the proportion of all HTTP redirects that carry the field. The header was originally proposed in [YOAST-PROPOSAL]. [RFC6648] discourages the "X-" prefix for newly defined header fields but makes no recommendation about whether an existing "X-" field ought to migrate. This document chooses migration: it defines Redirect-By as the successor field, specified as a Structured Field [RFC9651], and deprecates X-Redirect-By while registering it so the registry reflects what is on the wire (Section 4, Section 8). Existing implementations can send Redirect-By alongside X-Redirect-By during the transition (Section 4). 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The term "redirect" refers to a response with a 3xx (Redirection) status code (Section 15.4 of [RFC9110]), other than 304 (Not Modified), that contains a Location field. The "redirect decision-maker" is the component whose decision determines the Location field of a redirect response. It is not necessarily the HTTP server or intermediary that serializes or forwards that response. 3. The Redirect-By Field The "Redirect-By" response header field allows the redirect decision- maker to identify itself. A redirect decision-maker MAY include a Redirect-By field in the response. When present, its value SHOULD be a short, stable identifier for that component, such as a product, service, or plugin name. de Valk Expires 20 January 2027 [Page 3] Internet-Draft Redirect-By July 2026 The field is informational. A recipient MUST NOT treat the presence, absence, or value of Redirect-By as altering the meaning of the redirect; the Location field and status code retain their full semantics independent of it. A recipient that does not understand the field ignores it, as with any unrecognized field (Section 5.1 of [RFC9110]). 3.1. Syntax Redirect-By is an Item Structured Field [RFC9651]. Its value MUST be a Token (Section 3.3.4 of [RFC9651]) or a String (Section 3.3.3 of [RFC9651]) naming the redirect decision-maker; this document defines no parameters. For example: Redirect-By: WordPress or, for an identifier that a Token cannot carry: Redirect-By: "Yoast SEO Premium" Redirect-By is a singleton field, not a list. A sender MUST NOT generate more than one Redirect-By field line in a response. A recipient MUST process the field as a Structured Field Item; if that parsing fails, or the value is neither a Token nor a String, the recipient MUST ignore the field. This rule also disposes of duplicate field lines: combining them into a single value (Section 5.2 of [RFC9110]) produces a value that does not parse as an Item, so the field is ignored. The deployed X-Redirect-By field carries the identifier as free-form text rather than as a Structured Field; see Section 4. 3.2. Multiple Redirects and Intermediaries Where a request passes through several components that each redirect, each redirect is a separate response with its own decision-maker. Because a redirect is resolved one hop at a time, the value on any single response identifies the one component that determined the Location field for that hop. An intermediary that forwards a redirect response without changing its Location field SHOULD NOT add or modify Redirect-By, even if it modifies other parts of the response, such as the status code. An intermediary that changes the Location field thereby becomes the redirect decision-maker and MUST replace any existing Redirect-By value with its own identifier or remove the field. de Valk Expires 20 January 2027 [Page 4] Internet-Draft Redirect-By July 2026 4. Relationship to X-Redirect-By The information carried by Redirect-By has been deployed at scale under the non-standard name X-Redirect-By, which carries the identifier as free-form text: a sequence of visible ASCII characters, possibly with interior spaces, without Structured Field serialization. [RFC6648] recommends against the "X-" prefix for new fields and against assuming any semantic distinction based only on whether a name has that prefix. This document deprecates X-Redirect- By and defines the following migration behavior: * New implementations SHOULD send Redirect-By and SHOULD NOT send X- Redirect-By. * Existing implementations that send X-Redirect-By SHOULD also send Redirect-By, and SHOULD stop sending X-Redirect-By once the recipients they serve recognize the new name. * When an implementation sends both fields, both MUST name the same decision-maker, even though the serializations can differ: for example, X-Redirect-By: Yoast SEO Premium alongside Redirect-By: "Yoast SEO Premium". * Recipients SHOULD recognize both names. A Redirect-By field that is not ignored under the rules of Section 3 takes precedence over X-Redirect-By; a recipient MAY fall back to X-Redirect-By when Redirect-By is absent or ignored. Deprecation records that use of the X-Redirect-By name is discouraged; it does not make existing responses that carry it invalid, and recipients are expected to keep recognizing the legacy name while it remains widely deployed. 5. Design Considerations 5.1. A Structured Field [RFC9205] recommends that new HTTP fields use Structured Fields [RFC9651], and Redirect-By follows that recommendation. The deployed X-Redirect-By field predates this document and transmits its value as unquoted free-form text, so the two fields can differ on the wire: an identifier containing spaces is sent bare in X-Redirect-By but as a quoted String in Redirect-By. This document accepts that divergence. Migration already requires senders to adopt a new field name, so adopting the standard serialization at the same time costs little, and it buys well-defined parsing, an unambiguous rule for duplicate or combined field lines (Section 3), and the ability for future documents to extend the field with parameters. de Valk Expires 20 January 2027 [Page 5] Internet-Draft Redirect-By July 2026 6. Security Considerations Redirect-By is a voluntary disclosure of the identity of a redirecting component. It is not an authentication or integrity mechanism: its value is set by the sender and can be absent, forged, or copied, so a recipient MUST NOT rely on it to establish the provenance or trustworthiness of a redirect. Naming software in a response reveals information about a deployment that can aid an attacker in fingerprinting it. To limit this exposure, the value SHOULD be a coarse component identifier and SHOULD NOT include software versions, file system paths, internal host names, or the specific rule that matched. For example, "WordPress" is appropriate; "WordPress 6.5.2 via wp- content/plugins/acme/redirects.php:214" is not. Operators for whom any such disclosure is unacceptable can omit the field; it is optional. 7. Privacy Considerations The field describes server-side software, not the user. It carries no user identifier and introduces no new client-side state or tracking surface. 8. IANA Considerations IANA is requested to register the following two entries in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" defined in Section 18.4 of [RFC9110]. Redirect-By is requested as a permanent registration; the registry's procedure for permanent entries is Specification Required ([RFC8126]), for which this document is the specification. X-Redirect-By is requested with a status of "deprecated", documenting the name under which the field was widely deployed before this document and recording that its use is discouraged (Section 4). Registering the ubiquitous legacy name is a record of existing practice, not the minting of a new "X-" field, and is therefore consistent with [RFC6648]. Entry 1: * Field Name: Redirect-By * Status: permanent * Structured Type: Item * Reference: This document de Valk Expires 20 January 2027 [Page 6] Internet-Draft Redirect-By July 2026 * Comments: Successor to the deprecated X-Redirect-By field. Entry 2: * Field Name: X-Redirect-By * Status: deprecated * Structured Type: None * Reference: This document * Comments: Deprecated legacy name for the Redirect-By field (Section 3). 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9651] Nottingham, M. and P. Kamp, "Structured Field Values for HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024, . 9.2. Informative References [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, DOI 10.17487/RFC6648, June 2012, . de Valk Expires 20 January 2027 [Page 7] Internet-Draft Redirect-By July 2026 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC9205] Nottingham, M., "Building Protocols with HTTP", BCP 56, RFC 9205, DOI 10.17487/RFC9205, June 2022, . [TYPO3-REDIRECTS] TYPO3, "TYPO3 redirect and shortcut middleware emitting X- Redirect-By", n.d., . [WP-X-REDIRECT-BY] WordPress, "x_redirect_by filter", n.d., . [YOAST-PROPOSAL] Valk, J. de., "Let's introduce the X-Redirect-By header", n.d., . Acknowledgements The convention originated during the migration of _The Guardian_'s website from guardian.co.uk to theguardian.com, in which multiple systems issued redirects simultaneously, and was first proposed publicly in [YOAST-PROPOSAL]. The author thanks the WordPress core contributors who implemented X-Redirect-By [WP-X-REDIRECT-BY], and the maintainers of the other systems that adopted it, for establishing the deployed practice this document standardizes. Author's Address Joost de Valk Emilia Capital Email: joost@emilia.capital URI: https://joost.blog/ de Valk Expires 20 January 2027 [Page 8]