You're right there are two use cases here. It does sound like the pragmatic approach is to allow underscores in URL's normally, but to preserve the existing behaviour for those with stricter use cases, like you say.
I can also propose a solution that would still work for both: (deprecate > and) rename the current class to StrictURLValidator (or > URLValidatorRFC1034), to still be easily used for the less common scenarios. This sounds reasonable to me. I'm not sure we'd need the deprecation period, given we'd only be adding one character to URLValidator. A release note is typically enough in this situation, but I normally defer to the fellows for this. I think that would make Florian happy, although it *has* been seven years since his closing comment on the ticket. On Tue, 24 Mar 2020 at 16:41, Pavel Savchenko <asfalt...@gmail.com> wrote: > Hey folks, > > Sorry for not providing a more specific scenario before, was short on time > and just wanted to kick this off. > > The most common scenario that I can think of (and the one that most > similar to our usage) would be a *form field* on a Django site, that > allows users to input a URL which is saved and later displayed *as a link > to* other users (e.g in blogs, comments, CMS systems, etc). > > Here's an example of a site, though clearly not a very reputable one: > http://online_casino_news.hundredpercentgambling.com/ . Note that google > groups automatically converted this one to a URL for me, and I was able to > click and follow it both on Chrome and Firefox. > > In the above use case, by validating the correctness of the URL, we > protect a user from making a mistake, but we don't really care about > adhering to standards beyond that, the usability wins. > > There are other use cases, that might care about RFC 952 > <https://tools.ietf.org/html/rfc952>/1034 > <https://tools.ietf.org/html/rfc1034#section-3.5> guidelines about > hostname. For example, if we're building a hosting or a name server > management system, or maybe SSL certificates vendor. > In such cases, it might actually benefit the user if the platform alerts > on the validity of the hostname chosen by the user (at the very least to > advise the users). > > However, I would guess that the first use case, of taking a URL to store > and render it as a link, would be more common and thus more frequently > needing to override the class. > > I can also propose a solution that would still work for both: (deprecate > and) rename the current class to StrictURLValidator (or > URLValidatorRFC1034), to still be easily used for the less common scenarios. > > What do you think? > > Best Regards, > Pavel > > > On Tuesday, March 24, 2020 at 2:36:33 PM UTC+1, Adam Johnson wrote: >> >> Hi Pavel >> >> The ticket ( https://code.djangoproject.com/ticket/20264 ) doesn't >> mention any specific use cases, and nor have you. What has this behaviour >> blocked for you? >> >> Thanks, >> >> Adam >> >> On Tue, 24 Mar 2020 at 12:46, Pavel Savchenko <asfa...@gmail.com> wrote: >> >>> Hi Folks, >>> >>> I've just encountered this issue, and it seems Django's URLValidator >>> regex for host is trying to abide to RFC 1034 recommendation >>> <https://tools.ietf.org/html/rfc1034#section-3.5> , when there are many >>> sites in the wild that use underscore in their domain name. >>> >>> Can we please discuss this issue here, so we can eventually decide to >>> reopen the ticket (or not) and perhaps allow for a pull-request to fix it? >>> >>> I found this stackoverflow question helpful, with many answers/comments >>> with additional references: >>> https://stackoverflow.com/questions/2180465/can-domain-name-subdomains-have-an-underscore-in-it >>> >>> Best regards, >>> Pavel >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers (Contributions to Django itself)" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-d...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/6982245f-2b5a-4a32-8fe5-a063c7459b7c%40googlegroups.com >>> <https://groups.google.com/d/msgid/django-developers/6982245f-2b5a-4a32-8fe5-a063c7459b7c%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> Adam >> > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/2506854e-9566-444a-8f83-e227215613ea%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/2506854e-9566-444a-8f83-e227215613ea%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Adam -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM16Kng06PiWQdKMygDB-8yaxpqw-56SA5ux9XbMPk4oew%40mail.gmail.com.
