Repository navigation
int and float converters accept surprising values #3237
Description
I was looking at _plain_int and realized the int and float converters have similar issues to solve. In general, I think we want to prevent accepting multiple representations of the same value. For example, this is why the float converter already doesn't accept leading/trailing . like 4. or .2.
- Both converters accept non-ASCII digits such as
١٢٣. - The int converter accepts meaningless leading zeros.
- The float converter accepts meaningless leading zeros in the integer part, and meaningless trailing zeros in the decimal part.
- The float converter accepts numbers that overflow or underflow Python's
floatconversion, resulting in (-/+)0.0orinf. For example,1e400written as 1 followed by 400 zeros results ininf. - The int converter accepts more digits than
sys.get_int_max_str_digits()which causes aValueError(500) instead of aValidationError(404).
Pinned by davidism
davidismAfter thinking about this more, and looking through historical issues https://github.com/search?q=repo%3Apallets%2Fwerkzeug+converter&type=issues&state=closed&s=updated&o=desc, and looking at Django, I've decided to document the current behavior and leave it, while fixing some clear bugs.
- No one's actually reported issues about multiple representations being allowed, of it affecting caching, etc.
-
uuidconverter also accepts multiple representations, it allows mixed upper/lower case hex digits. - I don't know what existing URLs this might break. I have a feeling these are all edge cases and aren't deliberately created for legitimate reasons, but it could cause 404s that are hard to detect, …
Metadata
Metadata
Assignees
Labels
No labels
Activity
davidism commentedon Aug 13, 2026
I'm going to fix 5 in 3.1.5 since it was already an invalid URL. The others technically change what URLs are accepted even though they're all unintended, so I'll fix those in 3.2.
davidism commentedon Aug 13, 2026
The int leading zeros is complicated a bit by
fixed_digits. I guess if that's set, allow them since they don't result in duplicate representations. Also need to allow literal 0, since it starts with 0.davidism commentedon Aug 13, 2026
For float,
-0.0is a distinct value from0.0in some operations, but they are equal. I think I'll allow these since they may presumably be passed to something that cares about the sign.However, for int,
-0is not a distinct value, it's always0. I will disallow-0.davidism commentedon Aug 13, 2026
Also discovered that
signedinterfered withfixed_digits, meaning-was counted as one of the digits. This isn't how Python counts digits forsys.get_int_max_str_digits().All this validation is also not checked in
to_urland get somewhat complex, meaning it's possible to unintentionally generate URLs that won't match.davidism commentedon Aug 18, 2026
I keep going back and forth on whether to disallow "alternate" representations of the same float value. For example, Python will display
3.14e100as that, but if you format it withf"{3.14e100:f}"it's actually31399999999999998440121755087188611496023317657858142522962119136060321217693842207715753438069391360.0. Any values in between will all end up as the same value. Same thing happens for fractions.I have a robust float-to-string function now, and could call it when matching values to check that the URL contained that simple representation rather than another representation.
Python's
str(float)chooses the simplest representation using a really complex algorithm https://github.com/python/cpython/blob/95e32ba8262b2f08d4c574bce55425589cbf9885/Python/dtoa.c#L2154. Or at least I think it's always the simplest, I'm not sure that's guaranteed, so that might cause difficulty if not. But regardless, it would result in only one URL mapping to each unique float value. That seems good, but might be too unintuitive for people to guess at / know about floating point ranges.Another way to put it: I can ensure that there is a 1-to-1 mapping from URLs to unique float values, but it won't be intuitive/predictable in the same way that "no leading zeros" is.
davidism commentedon Aug 19, 2026
After thinking about this more, and looking through historical issues https://github.com/search?q=repo%3Apallets%2Fwerkzeug+converter&type=issues&state=closed&s=updated&o=desc, and looking at Django, I've decided to document the current behavior and leave it, while fixing some clear bugs.
uuidconverter also accepts multiple representations, it allows mixed upper/lower case hex digits.4.and.4are already not allowed, but this seems good as it's hard to spot. And4.especially is problematic in Markdown that might treat it as a period in URL detection. I think unambiguousleft.rightis still a good syntax to match, rather than allowing ints or trailing dots as well. So this doesn't change those previous decisions.inf, which is a genuinely unexpected result that could cause issues when using the value (similar but not as bad asnan). So I think overflow should be disallowed.decimalconverter that exactly preserves the input. It would still need to make decisions about leading zeros (decimal drops them) and trailing zeros (decimal considers them significant digits in calculations, decimal is used for currency, etc). It would need to be able to configurequantizelength and rounding behavior. This should have been done instead offloatto begin with, but then again no one's asked for this eitherstrict=Trueparameter to these converters to enable all these extra constraints. But again, no one's reported an issue with the current behavior.