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.
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)
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!
I miss Terry Pratchett. Just a good guy, writing joyful books. None of that "gritty realism" here. There's only about 40 books by him, so I read 2 a year. By the time I get to 40, I figure I would have forgotten the first few and I can start again.
My blog has had this header since the day he died.
I think strictly speaking any node on the network which receives the header should forward it on. So if your browser ever sees it, it should use it for all HTTP requests from that point. And if a server ever receives it, it should pass it to all clients.
I had that header set back when I ran my blog on my own HTTP server. Probably should spend some Cloudflare worker cycles to put it back now that it’s purely static…
Within the book itself the clacks system has its own technical protocol which is briefly touched upon. The "overhead" is essentially packet or request metadata.
From the LSpace wiki, GNU is a metadata that means:
G: Send the message onto the next Clacks Tower.
N: Do not log the message.
U: At the end of the line, return the message.
And yes, it is almost certainly a reference to GNU as in "GNU's Not Unix". =)
Why would it? Cargo Cutlting is when you believe that doing something symbolic will have a tangible effect on the world (e.g. bring you cargo from the sky), but this is just intended to be symbolic.
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.
https://datatracker.ietf.org/doc/html/rfc6648
What supposed problems does it cause in practice?
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.
> 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.
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)
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!
It might not have but it's a lot more likely that it would.
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.
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
There's a list of sites broadcasting X-Clacks-Overhead: https://xclacksoverhead.org/listing/the-signal
I miss Terry Pratchett. Just a good guy, writing joyful books. None of that "gritty realism" here. There's only about 40 books by him, so I read 2 a year. By the time I get to 40, I figure I would have forgotten the first few and I can start again.
My blog has had this header since the day he died.
There are Chrome and Firefox extensions to indicate the presence of the header.
https://chromewebstore.google.com/detail/clacks-overhead-gnu...
https://addons.mozilla.org/en-US/firefox/addon/x-clacks-over...
stackoverflow.com and all stack exchange sites also include X-Clacks-Overhead in the response thanks to yours truly
I think strictly speaking any node on the network which receives the header should forward it on. So if your browser ever sees it, it should use it for all HTTP requests from that point. And if a server ever receives it, it should pass it to all clients.
Honeypots are advertising that header as well nowadays:
https://www.shodan.io/search/report?query=x-clacks-overhead
Most of the non-honeypot results are for the Gargoyle Router Management interface exposed by Korea Telecom:
https://www.shodan.io/search/report?query=x-clacks-overhead+...
The results have increased significantly over time:
https://trends.shodan.io/search?query=x-clacks-overhead
I am all for goofy headers. Its especially fun when randomly stumbling into it.
I was poking at the AT&T U-Verse outage reporting endpoint and caught "X-Employment".
Sadly no additional challenge other than "If you are reading this, please consider a technology job at AT&T www.att.jobs".
Eww why would they buy a .jobs domain what a joke.
I had that header set back when I ran my blog on my own HTTP server. Probably should spend some Cloudflare worker cycles to put it back now that it’s purely static…
You don't need cloudflare workers for that. The blog post mentioned how to add it. And there are other options as well.
I have a fully static site. And the backing storage doesn’t let me set custom headers
Did you read the article? That method doesn't work for you?
What about this one? https://developers.cloudflare.com/rules/transform/request-he...
> But sometimes small, unnecessary things are exactly what make the internet better.
Or, worse? I don't think this is the point you're wanting to make but it's not always the case that it's better.
GNU Terry Pratchett
"A man never truly dies until the his name is no longer spoken."
Is this possibly an intentional reference to GNU Linux, or unrelated?
Within the book itself the clacks system has its own technical protocol which is briefly touched upon. The "overhead" is essentially packet or request metadata.
From the LSpace wiki, GNU is a metadata that means:
And yes, it is almost certainly a reference to GNU as in "GNU's Not Unix". =)https://wiki.lspace.org/GNU_Terry_Pratchett
It's Terry Pratchett, so of course it's an intentional reference.
Quite intentional.
A while back I wrote a tiny piece of Phoenix middleware to add the GNU message for an arbitrary name to phoenix applications:
https://github.com/alex0112/ex_clacks_overhead
I haven't touched it in years, so it's possible that it no longer works. But maybe this post is a kick in the pants for me to go test it again.
Thanks for keeping it in the overhead. GNU Terry Pratchett.
> "A man's not dead while his name is still spoken"
Looks like the site uses the deprecated "Report-To:" header in responses too, something I've never seen before and had to lookup.
Whenever you load my blog, it randomly sends back a name from my configuration's clackset: https://github.com/Xe/site/blob/ff8627975e5f6718fff33051d11a.... I hate that the list is so long but over time it will only grow longer.
Thank you for putting Matt trout there.
The most important HTTP header (though clacks is a packet routing system, not an application-level streaming protocol)
Well, there's no reason we couldn't have clacks-over-HTTP(-over-DNS)?(-over-avian-carrier)?, is there?
Of course, the good old CLOACA protocol (CLacks Over Avian CArrier), with the HTTP and DNS tunneling being OPTIONAL.
True, perhaps it should be added as an IP option field or TCP option...
Does “saying the name lest he be forgotten” classify as Cargo Cult?
Why would it? Cargo Cutlting is when you believe that doing something symbolic will have a tangible effect on the world (e.g. bring you cargo from the sky), but this is just intended to be symbolic.
I was curious, and you’re right. It would be Cargo Culting then, if we believed the ritual actually had an effect on Pratchett in the afterlife.