[garblegarble]

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

[lucideer]

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

[MrJohz]

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.

[Bratmon]

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

[lucideer]

It might not have but it's a lot more likely that it would.