Sadly no additional challenge other than "If you are reading this, please consider a technology job at AT&T www.att.jobs".
"A man never truly dies until the his name is no longer spoken."
Cargo cults are quite specifically believing that the incantations have an effect in this world.
"The first documented cargo cults were religious movements that foretold followers would imminently receive an abundance of (often Western) food and goods (the "cargo") brought by their ancestors."
What about this one? https://developers.cloudflare.com/rules/transform/request-he...
> 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.
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?"
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.
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: falseThat'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)
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.
But the header wouldn't have interacted with another header if we hadn't decided to do this X-prefix nonsense!
Perhaps there's a whole new joke format here.
Long-Face-Reason: horse
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.
My blog has had this header since the day he died.
https://chromewebstore.google.com/detail/clacks-overhead-gnu...
https://addons.mozilla.org/en-US/firefox/addon/x-clacks-over...
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"
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:
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.
stevekemp•1mo ago