It is incorrect to "normalize" // in HTTP URL paths

Re:It is incorrect to "normalize" // in HTTP URL paths by Mordisquitos on Saturday April 18, 2026 @06:21AM (#47814709)

> I can't imagine a real use case where you'd think this is desirable.

Not S3, but here's a literal real use case: the entry for the Iraqw word /ameeni (woman) in Wiktionary.

https://en.wiktionary.org/wiki//ameeni

If for whatever reason your S3 keys contained English words and their translations separated by a slash, you would have a real problem if one of your scripts were to concatenate woman, / and /ameeni as woman/ameeni instead of woman//ameeni in the English/Iraqw case.

[ Parent | on HN ]

Re:It is incorrect to "normalize" // in HTTP URL paths by zarzavat on Saturday April 18, 2026 @07:35AM (#47815075)

Sounds like a Unicode problem. U+002F is not a letter codepoint and it's not appropriate to use as a letter given its history of being used for path separation. Iraqw slash should have its own code point.

Can they not just use a 3 like in Arabic?

[ Parent | on HN ]

Re:It is incorrect to "normalize" // in HTTP URL paths by kstrauser on Saturday April 18, 2026 @06:46AM (#47814835)

If you’re working with a use case where that’s even possible, you need to URL-encode it like

  woman/%2Fameeni

Consider that if the language allowed trailing slashes. What would this path mean if ameeni/ happened to be a valid word?

  ameeni//ameeni

One of those would get the slash but it’s not clear which.

W3C says:

> The slash ("/", ASCII 2F hex) character is reserved for the delimiting of substrings whose relationship is hierarchical.

[ Parent | on HN ]