Opened 4 years ago
Closed 4 years ago
#30924 closed New feature (wontfix)
Numbers in top-level domain raise ValidationError
| Reported by: | Seth Foster | Owned by: | nobody |
|---|---|---|---|
| Component: | Forms | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
The current regex in URLValidator does not allow numbers in the top-level domain
e.g. www.example.org33 raises a ValidationError
Rarely, if ever, do public top-level domains contain a number, however internal, private networks can certainly be configured with numbers present in the top-level domain. Thus it is important to handle these URIs without having to specify custom regex patterns to pass into the URLValidator.
The change can be achieved by replacing the following line in the URLValidator class:
r'(?:[a-z' + ul + '-]{2,63}'
with
r'(?:[a-z' + ul + r'0-9' + '-]{2,63}'
Change History (1)
comment:1 by , 4 years ago
| Component: | Uncategorized → Forms |
|---|---|
| Resolution: | → wontfix |
| Status: | new → closed |
| Type: | Bug → New feature |
| Version: | 2.2 → master |
Note:
See TracTickets
for help on using tickets.
I'm going to suggest that creating a
URLFieldsubclass with an alteredURLValidatoris precisely the way to go here. I think the vast majority of users are not encountering TLDs including numbers.Since this would be a design change, please though follow-up on the DevelopersMailingList to discuss more fully. If there's consensus for a change there, then we could re-open as a New Feature.