Comments
By madeofpalk 2026-01-0315:532 reply FYI - no need to prefix your custom header with X- !
> Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs. In practice, that convention causes more problems than it solves. Therefore, this document deprecates the convention for newly defined parameters with textual (as opposed to numerical) names in application protocols.
If a nonstandard X header becomes widely used and then adopted as the standard, there is a surprisingly lengthy and difficult transition period to the new name.
Both clients and servers have to support both the X name and the regular name for decades, and servers have to deal with questions like "What if both are present but different?"
If both are present but different the unprefixed version should be favoured. That seems uncontroversial & not complex to implement.
Sending two headers seems fine in most cases.
These are certainly downsides but hardly dealbreakers. On the other side, not prefixing has its own pros & cons, which seem more difficult to work around:
1. The obvious clash issue. If two pieces of software implement entirely different X-Value: headers, the standardisation effort clarifies the signal in the form of an unprefixed version. If both competing software applications start out unprefixed, the signal will always be ambiguous.
2. Implementation changes. If any lessons are learnt during initial use of a prefixed header, these can be applied by standardising on a slightly improved unprefixed version.
By garblegarble 2026-01-0318:111 reply > If both are present but different the unprefixed version should be favoured. That seems uncontroversial & not complex to implement.
oops, you just enabled smuggling where there's a mismatch between what a proxy/firewall/etc supports and what an internal service supports.
X-Do-Evil: true Do-Evil: falseSmuggling is a general concern whenever two headers have functionality that interact - it's not specific to prefix masking & given how implementation-based it is, it's not even likely to occur to any arbitrary prefix mask.
That's not a reason not to consider it a threat vector when implementing, but no more than when implementing any header (that interacts with another)
By MrJohz 2026-01-0321:20 But isn't the problem with X- headers that if they ever get standardised, they necessarily create this smuggling issue? Whereas if you start with an unprefixed header and standardise it under the same name, you avoid this issue.
You could also solve the problem by standardising the header with the X- prefix, but this is more confusing to users and violates the idea that X- always means "not standardised", at which point the prefix is useless anyway.
> That's not a reason not to consider it a threat vector when implementing, but no more than when implementing any header (that interacts with another)
But the header wouldn't have interacted with another header if we hadn't decided to do this X-prefix nonsense!
By lucideer 2026-01-0410:03 It might not have but it's a lot more likely that it would.
By thrtythreeforty 2026-01-0315:50 There's a list of sites broadcasting X-Clacks-Overhead: https://xclacksoverhead.org/listing/the-signal
I have been guilty of adding a custom header to all of my emails: "Yo-Momma: Fat". For years. In a professional setting. Nobody noticed.
By akoboldfrying 2026-01-040:32 Discovering this at work one day would have brought a smile to my face!
Perhaps there's a whole new joke format here.
Long-Face-Reason: horse
