New draft: Redirect-By response header (draft-devalk-redirect-by-00)

Hi all,

First time e-mailer, but I thought I'd give it a try :)

I've submitted a first draft that defines the Redirect-By response header
field: https://datatracker.ietf.org/doc/draft-devalk-redirect-by/

Redirect-By lets the component whose decision determined a redirect
identify itself in the response. When a redirect is misconfigured, the
status code and Location tell you nothing about which of the CDN rules,
reverse proxies, CMS logic, or plugins in the chain produced it, so
diagnosis today usually means disabling components one at a time.

This field turns an opaque redirect into a self-describing one. This
standardizes existing practice. The convention originated during The
Guardian's migration from guardian.co.uk to theguardian.com (now quite a
while ago) and has shipped as X-Redirect-By in WordPress core since version
5.1 (sent by default on every redirect, with a filter so plugins can
identify themselves), in TYPO3's redirect middleware, and in a growing list
of other implementations.

Two design choices I'd particularly welcome feedback on:

1. The draft doesn't just add an unprefixed alias, it defines Redirect-By
as a Structured Field (an RFC 9651 Item, Token or String) and formally
deprecates X-Redirect-By, requesting registration of the legacy name with
status "deprecated". The reasoning: migration already requires senders to
adopt a new name, so adopting the standard serialization at the same time
costs little, and it gives well-defined parsing plus an unambiguous rule
for duplicate or combined field lines.

2. The field identifies the component that determined the Location field
specifically. An intermediary that rewrites only the status code leaves the
field alone; one that changes the Location must replace or remove it.

HTML rendering and issue tracker:

- https://jdevalk.github.io/draft-devalk-redirect-by/
- https://github.com/jdevalk/draft-devalk-redirect-by/issues

Comments here or as issues are both very welcome!

Joost de Valk

Received on Monday, 20 July 2026 14:03:23 UTC