[HN Gopher] X-Clacks-Overhead
___________________________________________________________________
X-Clacks-Overhead
Author : hleb_dev
Score : 104 points
Date : 2026-01-03 11:37 UTC (11 hours ago)
(HTM) web link (hleb.dev)
(TXT) w3m dump (hleb.dev)
| stevekemp wrote:
| Looks like the site uses the deprecated "Report-To:" header in
| responses too, something I've never seen before and had to
| lookup.
| hoppp wrote:
| I am all for goofy headers. Its especially fun when randomly
| stumbling into it.
| kotaKat wrote:
| 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".
| NewJazz wrote:
| Eww why would they buy a .jobs domain what a joke.
| atemerev wrote:
| The most important HTTP header (though clacks is a packet routing
| system, not an application-level streaming protocol)
| kijin wrote:
| Well, there's no reason we couldn't have clacks-over-
| HTTP(-over-DNS)?(-over-avian-carrier)?, is there?
| falcor84 wrote:
| Of course, the good old CLOACA protocol (CLacks Over Avian
| CArrier), with the HTTP and DNS tunneling being OPTIONAL.
| wiml wrote:
| True, perhaps it should be added as an IP option field or TCP
| option...
| danaris wrote:
| GNU Terry Pratchett
|
| "A man never truly dies until the his name is no longer spoken."
| xena wrote:
| 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.
| dylanh wrote:
| Thank you for putting Matt trout there.
| dejj wrote:
| Does "saying the name lest he be forgotten" classify as Cargo
| Cult?
| falcor84 wrote:
| 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.
| rcarmo wrote:
| 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...
| NewJazz wrote:
| You don't need cloudflare workers for that. The blog post
| mentioned how to add it. And there are other options as well.
| rcarmo wrote:
| I have a fully static site. And the backing storage doesn't
| let me set custom headers
| NewJazz wrote:
| Did you read the article? That method doesn't work for you?
|
| What about this one?
| https://developers.cloudflare.com/rules/transform/request-
| he...
| thrtythreeforty wrote:
| There's a list of sites broadcasting X-Clacks-Overhead:
| https://xclacksoverhead.org/listing/the-signal
| madeofpalk wrote:
| 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
| nubg wrote:
| What supposed problems does it cause in practice?
| Bratmon wrote:
| 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?"
| lucideer wrote:
| 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.
| garblegarble wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| wowczarek wrote:
| 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.
| maxmcd wrote:
| Is this possibly an intentional reference to GNU Linux, or
| unrelated?
| shadowgovt wrote:
| Quite intentional.
| kingsfoil wrote:
| 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". =)
|
| https://wiki.lspace.org/GNU_Terry_Pratchett
| nindalf wrote:
| 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.
| sandermvanvliet wrote:
| stackoverflow.com and all stack exchange sites also include
| X-Clacks-Overhead in the response thanks to yours truly
| regularfry wrote:
| 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.
| gclawes wrote:
| 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...
| kingsfoil wrote:
| 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"
___________________________________________________________________
(page generated 2026-01-03 23:00 UTC)