YAML: The Norway Problem (2022)
173 comments
·April 12, 2025weinzierl
Perl has a Poland Problem. The customary file extension for Perl files is *.pl. This worked well until Apache introduced content negotiation and the convention to add a language code as file extension. It had index.html.en, index.html.de, for example.
index.html.pl is where the problem started and the reason why the officially recommended file extension for Perl files used to be (still is?) *.plx.
I don't have the Camel book at hand, but Randal Schwartz's Learning Perl 5th edition says:
"Perl doesn't require any special kind of filename or extension, and it's better not to use an extension at all. But some systems may require an extension like plx (meaning PerL eXecutable); see your system's release notes for more information."
dtech
That sounds more like an Apache problem than a Perl problem. It's their mistake and it's not even relevant outside Apache context
maxloh
That should be marked as a breaking change on Apache side IMO. It would be a security nightmare if server code were leaked to public.
weinzierl
It should have been an Apache problem, yes. Not only did it turn out that at least the language negotiation part of content negotiation wasn't the best idea but the way Apache handled it was problematic apart from the pl problem. In the end the Perl community took the issue upon them, so historically I'd say it was a Perl problem (of choice).
gnabgib
Related
The YAML document from hell (566 points, 2023, 353 comments) https://news.ycombinator.com/item?id=34351503
That's a Lot of YAML (429 points, 2023, 478 comments) https://news.ycombinator.com/item?id=37687060
No YAML (Same as above) (152 points, 2021, 149 comments) https://news.ycombinator.com/item?id=29019361
mdaniel
And some light commentary a few days ago: https://news.ycombinator.com/item?id=43648263 - Apr 2025 (51 comments)
pkkm
Programming with string templates, in a highly complex and footgun-rich markup language, is one of the things I find most offputting about the DevOps ecosystem.
sph
I believe Satan itself decided to mix YAML, Jinja and Turing-complete logic when it created Ansible. It truly is the sendmail of the modern era.
senderista
Several years ago when I was writing a deployment system for a cloud distributed database, I tried to automate everything with Ansible playbooks and the Ansible "API" (LOL). I pretty quickly gave up on implementing anything but the most trivial logic in templated YAML and switched to Python (wrapping maximally-dumb Ansible playbooks) for everything nontrivial.
Fizzadar
You might like pyinfra.
mdaniel
Just about every time someone complains about ansible, there's a comment to plug this project but pyinfra seems to opt-out of the cloud provisioning part, instead delegating to its terraform connector, which drags in all the nonsense that entails. That makes it not only less useful but (IMHO) a horrible name for a project that only does "remote execution" and not infrastructure. The fact that it's even missing @aws @azure @gcp connectors further solidifies "who is the audience for this thing?"
nicktelford
This is why I generally use Terraform for Kubernetes. It's not perfect, but it's miles better than the various different YAML-templating solutions (Kustomize, Helm) popular in the Kubernetes ecosystem.
mdaniel
Two different stateful recordkeeping control planes with disparate opinions about the current state of the world. What can go wrong.
sofixa
To be fair one of the most common ways of managing Kubernetes clusters and what is deployed on them is to use ArgoCD, which gives you the same issue of dual stateful control planes.
Even more fun is if you then run your Kubernetes cluster on top of a VM orchestrator such as vSphere, that way you have multiple layers of stateful control planes and compute orchestrators fighting each other.
anvandare
"The limits of my keyboard mean the limits of my programming language."
If only they had had ⊥ and ⊤ somewhere on their keys to work with Booleans directly while designing the languages. In another branch of history, perchance.[1]
[1] https://en.wikipedia.org/wiki/APL_(programming_language)#/me...
#/media/File:APL-keybd2.svg){kind=link}
tossandthrow
⊥ and ⊤ is not entirely congruent to false and true.
Boolean and propositional logic is not the same.
Q6T46nT668w6i3m
For _ordinary_ two‑valued classical propositional logic, e.g., YAML, they are congruent.
rusk
I have an emacs macro for this
whacko_quacko
Pandas has a Nigeria problem, where NA -> NaN.
It's not that bad, because you can explicitly turn that behavior off, but ask me how I know =(
orangewindies
That's a Namibia problem, Nigeria is NG.
whacko_quacko
Damn, you're right ^^' Thanks for pointing that out
trueismywork
How?
whacko_quacko
For example when reading a CSV. Try using `read_csv` on a file that contains two letter country codes including NA.
alkonaut
Always quote all yaml strings. If you have a yaml file that has something that isn't a simple value (number, boolean) such as for example a date, time, ip-address, mac address, country code, phone number, server name, configuration name, etc. etc. then you are asking for trouble. Just DON'T DO THAT. It's pretty simple.
"Yeah but it's so convenient"
"Yeah but the benefit of yaml is that you don't need quotes everywhere so that it's more human readable"
DON'T
ohgr
Yeah that.
00,01,02,03,04,05,06,07,OH SHIT
ashishb
How often do people even encounter this issue? I have been using YAML for 5+ years and have never had it before. Further, I use `yamllint` which points this out as a lint issue "truthy value should be one of [false, true]".
tetha
I don't recall encountering the norway problem in the wild.
Ansible has a pretty common issue with file permissions, because pretty much every numeric representation of a file mode is a valid number in YAML - and most of them are not what you want.
Sure, we can open up a whole 'nother can of worms if we should be programming infrastructure provisioning in YAML, but it's what we have. Chef with Ruby had much more severe issues once people started to abuse it.
Plus, ansible-lint flags that reliably.
hinkley
Fractions are discriminatory when they happen to one individual or group every time or even just the first time.
See also p95 but the same couple of users always see the p99 time, due to some bug.
ashishb
Indeed, based on the comments, it is a scissor-bug. Most people never encountered it while some encountered it a lot.
rat87
I have when getting an openapi yaml file from someone else.
jeltz
I have seen it twice but I work in Sweden where we often do things also for the Norwegian market.
mongol
Has been encountered where I work. A global website with lots of country-specific config.
speedgoose
I have encountered it once, though I live in Norway and worked in IT there for a decade.
Y-bar
Never experienced it for the past 10+ years since the bug was fixed in the spec.
Y_Y
I don't think false is truthy.
quechimba
We had this issue many years ago when people from Norway couldn't sign up. Took us a while to figure out
dmckeon
Narrow escape for people from Yemen (YE).
magicalhippo
As a Norwegian I'm very curious, where in the pipeline were you using YAML? And why?
I've only seen it used for configuration.
StableAlkyne
I've seen teams use it as a replacement for JSON because it has the perception of being more "modern"
bornfreddy
While JSON is annoying because it lacks some pretty basic features (comments, trailing comma), at least its spec is short. YAML is huuuge - there are way too many ways to do the same thing.
null
quechimba
We were using a fork of https://github.com/carmen-ruby/carmen/tree/master/iso_data/b... with our own translations. We used the data in the signup form.
tough
usually locale's paths gone wrong
TZubiri
I usually think of yaml for internal config files, would never think of yaml for user data.
Don't ask me why though, might have something to do with how it's written like a python file, no user would want to write their data in yaml format.
nurgasemetey
Probably, OP didn't keep user data in YAML, but I think there was config that kept allowed countries to sign up.
null
duxup
Or were they from Noway ...
umanwizard
“Be liberal in what you accept” rears its ugly head once more.
eyelidlessness
Being liberal in what you accept, also known as the “robustness principle”, doesn’t mean being ambiguous or surprising about how you accept it. If anything, robustness requires a great deal more precision and clarity (at least with your own reasoning, then with how you communicate what to expect from it).
kazinator
Postel's Law does not deserve to be nicknamed the Robustness Principle.
Robustness has a meaning and it refers to handling bad inputs gracefully. An example of a lack of robustness is allowing a malicious actor to execute arbitrary code by supplying a datum larger than some buffer limit.
Trying to make sense of invalid inputs and do something with them isn't robustness. It's just example of making an extension to a spec. The extension could be robust or not.
Postel's Law amounts to "have extensions and hacks to handle incorrectly formatted data, rather than rejecting them. So, OK, yes, that entails being robust to certain bad inputs that are outside of the spec, but which land into onto one of the extensions. It doesn't entail being robust to inputs that fall outside of the core spec and all hacks/extensions.
Cherry picking certain bad inputs and giving them a meaning isn't, by itself, bona fide robustness; robustness means handling all bad inputs without crashing or allowing security to be compromised.
hinkley
Pandering to customers will make you a lot of money today but very narrow margins tomorrow. If you’re in startup mentality your bosses may be 100% fine with that. But you will likely be stuck supporting that crap because you didn’t become wealthy in the IPO/merger.
munch117
Postel's law isn't about accepting arbitrary invalid inputs. It's about inputs that are technically invalid but the intent is obvious from looking at it, and handling those according to intent.
In a distributed non-adversarial setting, this is exactly what you want for robustness.
The problem, as we've come to realise in the time since Postel's law was formulated, is that there is no such thing as a distributed non-adversarial setting. So I get what you're saying.
But your definition of robustness is too narrow as well. There's more to robustness than security. When Outlook strips out a certificate from an email for alleged security reasons, then that's not robustness, that's the opposite, brokenness: You had one job, to deliver an attachment from A to B, and you failed.
Robustness and security can be at odds. It's quite OK to say, "on so and so occasion I choose to make the system not robust, because the robust solution would not be sufficiently secure".
senderista
That works only when everyone is trying in good faith to follow the standard, i.e. basically never. My version of Postel's Law:
If you accept crap, then eventually you will receive only crap.
inopinatus
This has little to do with the robustness principle, however mis-stated. It's just shitty design. But if someone was still hell-bent on invoking it, then if anything, it's a straight-up violation of the adjacent words "be conservative in what you do"¹, and further disregards the commentary in RFC1122²:
... assume that the network is
filled with malevolent entities that will send in packets
designed to have the worst possible effect ...
xelxebar
This has been fixed since 2009 with YAML 1.2. The problem is that everyone uses libyaml (_e.g._ PyYAML _etc._) which is stuck on 1.1 for reasons.
The 1.2 spec just treats all scalar types as opaque strings, along with a configurable mechanism[0] for auto-converting non-quoted scalars if you so please.
As such, I really don't quite grok why upstream libraries haven't moved to YAML 1.2. Would love to hear details from anyone with more info.
[0]:https://yaml.org/spec/1.2.2/#chapter-10-recommended-schemas
xigoi
I’m sad that the “fix” was to disallow “no” as a more readable alternative to “false”, rather than to disallow unquoted strings.
mckn1ght
It’s silly to have so many keyword synonyms as specified in that earlier regex. I’m also glad we can’t specify numeric literals as roman numerals. KISS
xigoi
Honestly I’d prefer if “yes” and “no” were the only ways to spell the boolean values. They make sense in pretty much all contexts where booleans are used, whereas “true” and “false” rarely make sense.
xelxebar
The fix is to make conversion user-controllable. If you want to disallow bare scalars except for booleans and numbers or whatever, it's just a little bit of configuration away.
heavenlyblue
Why do you need an alternative spelling of false?
xigoi
`logging: no` clearly says “I do not want logging”. `logging: false` is less explicit – what exactly is false?
pydry
Yeah, you still get the same issue that 3 is an integer, 3.3 is a float and 3.3.3 is a string.
maxloh
Why wasn't that a major version bump, like YAML 2.0?
That sounds like a breaking change that rendered old YAML documents to be parsed differently.
transfire
Absolutely correct! Please correct me if I am wrong, but as far as I know, no one has implemented YAML completely according to spec.
The tag schema used is supposed to be modifiable folks!
And why anyone would still be using 1.1 at this point is just forehead palming foolishness.
xelxebar
AFAIK, libfyaml[0] (not to be confused with libyaml) passes the 1.2 test suite, and if I remember correctly, it's currently the only YAML loader with that claim at the moment.
The yaml.orf website also lists a bunch of implementations, with about 1/3 supporting 1.2. I'm guessing that the users of those libraries just happily hum along and we never hear from them!
The issue is that downstream consumers of popular languages with a vocal community here on HN tend to just pull in libyaml, PyYAML being the major offender in my mind.
nnurmanov
Another solution is to change the country name:)
gunalx
Thoug we have renamed amino acidsvi think it was. Because microsoft excel switched the original names to months.
madcaptenor
Genes, not amino acids.
https://www.theverge.com/2020/8/6/21355674/human-genes-renam...
gunalx
Thanks for corrections.
Even worse is the all-decimal MAC problem.
Some genius decided that, to make time input convenient, YAML would parse HH:MM:SS as SS + 60×MM + 60×60×HH. So you could enter 1:23:45 and it would give you the correct number of seconds in 1 hour, 23 minutes, and 45 seconds.
They neglected to put a maximum on the number of such sexagesimal places, so if you put, say, six numbers separated by colons like this, it would be parsed as a very large integer.
Imagine my surprise when, while working at a networking company, we had some devices which failed to configure their MAC addresses in YAML! After this YAML config file had been working for literal years! (I believe this was via netplan? It's been like a decade, I don't remember.)
Turns out, if an unquoted MAC address had even a single non-decimal hex digit, it would do what we expected (parse as a string). This is not only by FAR the more common case, but also we had an A in our vendor prefix, so we never ran into this "feature" during initial development.
Then one day we ran out of MAC addresses and got a new vendor prefix. This time it didn't have any letters in it. Hilarity ensued.
(This behavior has thankfully been removed in more recent YAML standards.)