The Spec Said 3.2.0. Your Runtime Says 17.0.0.

A function that looks like ordinary string handling can quietly disagree with a twenty-year-old internet standard when the runtime ships newer data than the spec assumed. The mechanism is not a bug in the usual sense. It is a version string.

Seth Larson's post pins the gap: a current CPython build reports unicodedata.unidata_version of 17.0.0, while the IDNA 2003 and StringPrep standards were frozen against Unicode 3.2.0. Code that does case folding inside those standards paths inherits the newer table, then disagrees with any other processor that did not. Two filters can "see" the same hostname and reach opposite verdicts, which is the shape of an SSRF.

The reusable category is versioned-spec drift: published standards age into a world that has moved on, and the gap is invisible until something collides. The audit is one line (compare unidata_version to 3.2.0); the fix is already in the standard library (unicodedata.ucd_3_2_0), and new code should use the idna package rather than the stdlib codec. Most code is unaffected. The rest is a one-line check away.