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

I like this.

To be clear, there's no requirement for any of those intermediaries to
register 'their' value? For example, it may be that a CDN called "The Cool
CDN" might always add `Redirect-By: coolcdn`or  `Redirect-By: cool` or
`Redirect-By: cdn` or even `Redirect-By: "Blah blah blah"` - they can
choose to use whatever value they want, although it would be in everyone's
best interests for companies to standardize on a value they choose to
specify?

Obviously this means that if a hacker were able to MitM the response
processing, they could add the `Redirected-By: coolcdn` response header,
and hope that the client would incorrectly believe that the redirect was
'legitimate'?

I think the only concern would be making it very very very clear that this
header can't be trusted, and is really most useful when debugging request
problems.

On Mon, Jul 20, 2026 at 7:07 AM Joost de Valk <joost@joost.blog> wrote:

> 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
>


-- 
Rory Hewitt

https://www.linkedin.com/in/roryhewitt