URL validation redesign and modernization

[Ludwig Kraatz]

Abstract

An URL is a way of describing a Resource.

​https://resource -> is a valid URL.

Why do i raise this as issue

An URL resource-descriptor is constructed like that [RFC 3986#section-3]:

         foo://example.com:8042/over/there?name=ferret#nose
         \_/   \______________/\_________/ \_________/ \__/
          |           |            |            |        |
       scheme     authority       path        query   fragment

so: scheme, authority, rest...

The issue in djangos URLValidation I want to address, is a over-specification and 'selective circumvention of wrongful parsing' when it comes to the -host- compnent of the authority part.

What djangos URLValidator currently does:
host_re = "( FQDN-REGEX | localhost )"

Basically, django parses IP-OR-FQDN-OR-LOCALHOST-URLs.

This is basically the 'selective circumvention of wrongful parsing' i mentioned earlier. By ”| localhost" the URL field "feels" more okay, because all the obvious URLs on localhost that exist, now pass. But there is so much more than "localhost" besides FQDN as used for "(global) DNS URLs".

The RFC also acknowledges this. It is recommending using a syntax for hosts that conforms to the DNS syntax.

​https://datatracker.ietf.org/doc/html/rfc3986#section-3.2.2

A host identified by a registered name is a sequence of characters
   usually intended for lookup within a locally defined host or service
   name registry, though the URI's scheme-specific semantics may require
   that a specific registry (or fixed name table) be used instead.  The
   most common name registry mechanism is the Domain Name System (DNS).
   A registered name intended for lookup in the DNS uses the syntax

   defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123].
   Such a name consists of a sequence of domain labels separated by ".",
   each domain label starting and ending with an alphanumeric character
   and possibly also containing "-" characters.  The rightmost domain
   label of a fully qualified domain name in DNS may be followed by a
   single "." and should be if it is necessary to distinguish between
   the complete domain name and some local domain.

      reg-name    = *( unreserved / pct-encoded / sub-delims )

   If the URI scheme defines a default for host, then that default
   applies when the host subcomponent is undefined or when the
   registered name is empty (zero length).  For example, the "file" URI
   scheme is defined so that no authority, an empty host, and
   "localhost" all mean the end-user's machine, whereas the "http"
   scheme considers a missing authority or empty host invalid.

   This specification does not mandate a particular registered name
   lookup technology and therefore does not restrict the syntax of reg-
   name beyond what is necessary for interoperability.  Instead, it
   delegates the issue of registered name syntax conformance to the
   operating system of each application performing URI resolution, and
   that operating system decides what it will allow for the purpose of
   host identification.  A URI resolution implementation might use DNS,
   host tables, yellow pages, NetInfo, WINS, or any other system for
   lookup of registered names.  However, a globally scoped naming
   system, such as DNS fully qualified domain names, is necessary for
   URIs intended to have global scope.  URI producers should use names
   that conform to the DNS syntax, even when use of DNS is not
   immediately apparent, and should limit these names to no more than
   255 characters in length.

What is said in many ways:

• local host resolution is completely okay.
• no "." is required as, a sequence (which is not further specified to length restrictions) can consist of 1, which would lack a "." seperator
• host names that are -compatible-, are valid.

[RFC 6762 Multicast DNS # Section 3]

It is unimportant whether a name ending with ".local." occurred
   because the user explicitly typed in a fully qualified domain name
   ending in ".local.", or because the user entered an unqualified
   domain name and the host software appended the suffix ".local."
   because that suffix appears in the user's search list.

It is stated clearly, that a user can describe a resource with the implication, that if its not a fully qualified domain name, the TLD .local is to be assumed. As such - the URL, which is what the user would be referencing, was to be able to deal with more non-FQDN than just "localhost". This is in the context of Multicast DNS, which seems more than close enough to be considered relevant, when talking about URLs - as the URL RFC was so closely described around DNS.

[RFC 3986 URI/URL # 1.1]

 URIs that
   identify in relation to the end-user's local context should only be
   used when the context itself is a defining aspect of the resource,
   such as when an on-line help manual refers to a file on the end-
   user's file system (e.g., "file:///etc/hosts").

• clearly states, that URI's are valid, even if they clearly only 'make sense' in a end-users local context.

As such - restricting django URLs to only Fully Qualified Domain Names/IPs, (except localhost.. for whatever reason except inconsitency :-* ) - is a restriction that contradicts that notion.

What i am proposing:

fully allowing for URLs as per rfc3986#section-3.2.2 - with a regex solution for localhost (and whatever else is possible) instead of a hardcoded < "magicnumber"-80%-"solution" >

To be Commited to django repository and pull requested. My earlier pull request is more - a starting point for discussion.

Why this is necessary & usefull:

Single-label URLs might be used

• in intranet situations
• for URLs that represent services / schemes that do not comply to FQDNaming conventions
• for local testing (local DNS resolution that is not based on FQDN)
• mDNS [RFC 6762] solutions, operating under .local TLD (which as of that RFC can be ommitted in a local context)
• the django validator is named URLValidator, not FQDN_IP_LOCALHOST_URLValidator

Further notes:

i already submitted a pull request - which probably isn't mature enough.. given i did not even check which tests would break..

EDIT: ignore the following. it was an oversight on my end.

but - there was one test, that should not have broken:

FAIL: test_urlfield_clean_invalid (forms_tests.field_tests.test_urlfield.URLFieldTest.test_urlfield_clean_invalid) [<object object at 0x000001C1038C1760>] (value='foo')

URL <= "foo" should not be valid, even with my little changes, replacing 'localhost' with hostname_re

It feels like there are some (- -)  missing - but i did not check.. i focused on providing a more solid ticket first..
So - if i am not mistaken, there is another issue besides what i propose. It seems, limiting hosts via FQDN was the thing, preventing missing URI-scheme's to be rejected by the validator, not a correct validation of uri-schemes themselves.

PS

its kindof late - i might polish this ticket tomorrow. if you feel like i'm drunk or disorganized - its just my brain thats screaming for relief. sry.

[Ludwig Kraatz]

​https://github.com/django/django/pull/19095

[Ludwig Kraatz]

​https://github.com/django/django/pull/19096

Test cofirmed: URL Validation fails for "localhost" => which will be accepted, even though its not a valid URL. (it lacks scheme://)

Bottom line: whole regEx / Validation seems off on multiple layers.

[Sarah Boyce]

This is rather hard to follow, http://localhost is a valid url and passes. localhost is not a valid url and fails. I do not follow the reasoning that there is an issue

[Ludwig Kraatz]

hello=??

​https://github.com/django/django/pull/19096

look at your own test cases. localhost is being allowed, even though we agree it should not. so that issue stands as it is. Your current code contradicts your own statement. It stands on its own - and has nothing really to do with this ticket on its own. so why you close it with that rational after it has been assigned to me - sry, i dont get it.

My ticket, initially, was about http://somethingOtherThanLocalhost -> is valid as well. But is falsefully rejected by the URLvalidator.

Both issues combined say: The whole RegEx URLValidator logic is off.
as mentioned - on multiples layers

1. the issue of not conforming to reality, by not allowing https://resource or https://printer or whatever 'local' but non-localhost resource is to be referenced.
2. the issue of being a wrong regex, as it allows things that are clearly not to be allowed.

please take some more time to reconsider closing this ticket in a hurry - this is not thought through.

[Ludwig Kraatz]

Replying to Sarah Boyce:

This is rather hard to follow, http://localhost is a valid url and passes. localhost is not a valid url and fails. I do not follow the reasoning that there is an issue

i have to correct you here:

localhost is not valid but passes.

look closely at:
​​https://github.com/django/django/pull/19096

 FAIL: test_urlfield_clean_invalid (forms_tests.field_tests.test_urlfield.URLFieldTest.test_urlfield_clean_invalid) [<object object at 0x000002C811AD0FE0>] (value='localhost')
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\hostedtoolcache\windows\Python\3.13.1\x64\Lib\unittest\case.py", line 58, in testPartExecutor
    yield
  File "C:\hostedtoolcache\windows\Python\3.13.1\x64\Lib\unittest\case.py", line 556, in subTest
    yield
  File "D:\a\django\django\tests\forms_tests\field_tests\test_urlfield.py", line 114, in test_urlfield_clean_invalid
    with self.assertRaisesMessage(ValidationError, msg):
    ^^^^^^^
  File "C:\hostedtoolcache\windows\Python\3.13.1\x64\Lib\contextlib.py", line 148, in __exit__
    next(self.gen)
    ^^^^^^^
  File "D:\a\django\django\django\test\testcases.py", line 807, in _assert_raises_or_warns_cm
    with func(expected_exception) as cm:
    ^^^^^^^^^^^^^^^
  File "C:\hostedtoolcache\windows\Python\3.13.1\x64\Lib\unittest\case.py", line 263, in __exit__
    self._raiseFailure("{} not raised".format(exc_name))
    ^^^^^^^
  File "C:\hostedtoolcache\windows\Python\3.13.1\x64\Lib\unittest\case.py", line 200, in _raiseFailure
    raise self.test_case.failureException(msg)
    ^^^^^^^^^^^^^^^
AssertionError: ValidationError not raised

TLDR:

1. forms_tests.field_tests.test_urlfield.URLFieldTest.test_urlfield_clean_invalid)(value='localhost')
2. AssertionError: ValidationError not raised

[Ludwig Kraatz]

Host components, and whether they are being validated correctly or not.

This - is the core issue of my ticket.

+---------------------+
|  Local Environment  |
+---------------------+
       |
       |--[localhost]---> VALID
       |
       |--[printer]------> FALSELY INVALIDATED
       |                    (valid via local DNS, mDNS, or hosts)
       |                    (although it was explicitly claimed a valid utilization as of RFC6762)
       |
       |--[printer.local]-> VALID

+---------------------+
|  Public Environment  |
+---------------------+
       |
       |--[example.com]---> VALID

[Sarah Boyce]

If you "look closely" at the test, you will notice it is testing URLField, not URLValidator.

URLField has the feature ​assume_scheme which means the normalized value is http://localhost and, therefore, URLValidator finds it valid.

If you can run the following code against URLValidator:

>>> from django.core.validators import URLValidator
>>> URLValidator()("http://localhost")
>>> URLValidator()("localhost")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/path_to_django/django/core/validators.py", line 170, in __call__
    raise ValidationError(self.message, code=self.code, params={"value": value})
django.core.exceptions.ValidationError: <exception str() failed>

So, URLValidator raises a ValidationError when called against localhost.

[Ludwig Kraatz]

Replying to Sarah Boyce:

If you "look closely" at the test, you will notice it is testing URLField, not URLValidator.

URLField has the feature ​assume_scheme which means the normalized value is http://localhost and, therefore, URLValidator finds it valid.

If you can run the following code against URLValidator:

>>> from django.core.validators import URLValidator
>>> URLValidator()("http://localhost")
>>> URLValidator()("localhost")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/path_to_django/django/core/validators.py", line 170, in __call__
    raise ValidationError(self.message, code=self.code, params={"value": value})
django.core.exceptions.ValidationError: <exception str() failed>

So, URLValidator raises a ValidationError when called against localhost.

would have been an nice addition to your closing comment - as it would have pointed out an obvious oversight on my end.

still - has nothing to do with my actual ticket.

[Sarah Boyce]

Thank you for the ticket Ludwig. Apologies I didn't give more context as to why I found the ticket confusing

I have revised this to be a new feature, rather than a bug, as this is a change of behavior which has downstream consequences and not everyone would want to accept these URLs
This would likely want to be configurable, similar to schemes, possibly with an allow all option.

Our process for requesting features is to first propose and discuss the idea with the community and gain consensus. To do that, please consider starting a new conversation on the ​Django Forum, where you'll reach a broader audience and receive additional feedback.

If the community agrees with the proposal, please return to this ticket and reference the forum discussion so we can re-open it. For more information, please refer to ​the documented guidelines for requesting features.

[Tim Graham]

If the summary is accurate, it appears to be a duplicate of #25418.

[Ludwig Kraatz]

Thank you Sarah, for putting in the effort - and taking the time for this ticket.

Really a Bug || hope you reconsider || though i do see the point (to a degree)

I do not consider this a new feature - I consider this correcting a misleading/outdated implementation of URLValidator.
I hoped to have pointed out, that how URLs are defined via RFC 3986 and the context of RFCs sourrounding it - is not the same as how the django URLValidator validates them.

​https://github.com/django/django/blob/9cc3970eaaf603832c075618e61aea9ea430f719/docs/ref/validators.txt#L182
Even consider how the django docs talk about the URLValidator.
There stated, plain and simple ("in other words"): it does not validate URLs, but what django considers relevant and "URL-Looking".

    A :class:`RegexValidator` subclass that ensures a value looks like a URL,
...
            Values starting with ``file:///`` will not pass validation even

I do understand the downstream implications. Which is why I added this ticket after my initial "pull request" (not talking about the quality of that request here..) - and the tests it broke.

I do see how one could argue, that django operates mostly in the Web domain and as such the URLField validating those kind of URLs seems reasonable.
But then again - adding a hardcoded 'localhost' really is making this argument a little obsolete. Because, try https://localhost on a machine that is not set-up to serve that resource.. It's the exact same as https://printer. If it is set-up - it works. if not, it does not. Only difference - it is easier for developers using django.
Buut that makes it superficial - no offense. I made that argument before.. I will elaborate on why "superficial naming" is a bug

Just to make the inconsistency clear:
localhost was reserved with RFC 6761.
The mDNS, which django's URLValidator (as an EXAMPLE) 'violates', was RFC 6762.
Both from 02.2013.
The URLValidator is from before that. Im pretty sure i used it back in 2010/11.

The field is not called a "DNSURLField" or "WebURLField" or "CustomURLField" - and as such, the implementation simply does not match what it claims to be.
Which, in turn, leads to very circumventable problems.

Oh my..
​https://github.com/django/django/blob/9cc3970eaaf603832c075618e61aea9ea430f719/django/core/validators.py#L169

i just realized django "actually" implemented a "CustomWeb2010"URLValidator - calling it URLValidator..

I really want to "emphasize", that naming some "thing" plays a crucial role in what that thing should "do" or what that thing will be "expected to do". And as such - this plays a crucial role Quality-wise, especially for a "framework for perfectionists (with deadlines)" -- if thats still what django is labeled, as it was back when i started.

Why it matters || projects depend on django being 'reliable' || a concrete example

The thing is, django is a framework, not a "simple project".

Projects like Authentik depend on the conformity of things like the URLValidator in django:
​https://github.com/goauthentik/authentik/blob/3daa39080a7866d83fad0fb3691e9e31397e0f6c/authentik/providers/saml/models.py#L43

We use authentik in our intranet. We use it as a SAML IDP.
It interacts with other Third-Party tools in our intranet. But - the intranet aspect is actually irrelevant here.
The SAML Service Provider dictates its ACS-URL.

As such, using the URLs in a way the URLValidator currently (falsefully) rejects, is mandatory for us.

Its a Software that defines its ACS-URL as "​https://example/resource" (other words, but thats the layout. BTW: do you see how the URL is accepted here as URL. I did not decalre it as some sort of link.)
And that works just fine, because this URL is only used for validation, that a SAML request is meant for the endpoint it is handled at. No URL-"Calling" happens.
Its a simple reference, in the form of an URL. A reference for a resource via its location.
The location is locally-scoped, sure. But we live in 2025+. Not back in pre-2010, where the only things happening was in the WEB or FS. (stupid remark, i know. i am sorry.)

And as this software handles that all internally - it does work without anything to be setup on (m)DNS / Host or else.
Its just another application running - as if a normal user would install something from some software-store (that just as well might run as "​https://localhost"... but in this case, it simply doesn't)

Why it matters, even in standard configurations

Again, RFC 6762 talks about mDNS -> which is a standard that gains (as part of a whole zeroconf thing) more and more relevance in everyday IT-usage.
It is natively supported in MacOS, ships in the default of some Linux distros and just take Apple's Bonjur (as example mDNS implementation).

​file:/// - is a URL. it might not be a "WebURL" or "DNSURL", but - it is a URL.
Developers expecting django to handle URLs might suffer headaches, because.. it simply "does not".
And they might by completely caught off guard, because this DjangoURL-Field is so non URLy.

Naming things falsefully, creating a misconception of what they do, is hindering us and others in simply utilizing a well organized infrastructure of software.
Which i would say is the goal of open-source at its core..
Which - brings me to, why this is a bug, not a feature.

A software that so obviously does that - is buggy.
I came here, to fix that, or at least make sure i did my part - as good as i can.

Possible Proposition

This is how i would do it. I get, if a URLField(mode_feature='raw') - is something you are leaning towards.
I simply would not do it that way, as I see it as an evolutionary adaption&correction, not just a feature.

1. Deprecation of URLField (as it never was, what it was called)
2. creation of
   • RawURLField + RawURLValidator
   • WebURLField + WebURLValidator // CustomURLField/Validator
     • subclassing Raw*,
     • adding lazy-scheme, other restrictions and default stuff for backwards compatability

(even though i would prefer something like URL_Web__Field/URL_Raw__Field - or even better Field__URL_Web/.., but thats totally irrelevant in a django context...)

Benefits:

• it is very clear (at least clearer) what one would get
• one has to make a conscious decision about what the own usecase is
• it would have to be a development-change that is to be made, instead of another option on the URLField/Validator, that is probably ignored more often than good.

This way - sure - there are some hurdles when updating a projects django dependency.
But thats to be expected in a changing environment or when implementation simply was not spot on.
This way, at least everybody can decide consciously, with which to go for.

And I do see, how you would want to include the forum on this topic - but i simply don't.
I see a bug - i report it, i put in effort for people to see and understand it and i offer my help fixing it.
But i dont "do people". Sry, but not sry. And most certainly no offense (: I have to look in the mirror from time to time - so, i'm no different then the rest of us.
But, i don't lobby or discuss options - especially not with the django community.
I tried that back then - i was shut down, pretty similar to how this almost ended up. Just to see my suggestion being implemented after little time has past - because it was the only thing that made sense....
It does not work "for/with me" - if "you" have to consult your community for "how you" want to approach this. I'm totally ok with that.

I just brought a bug to your attention, and offered my help.
As this ticket remains closed, so does my involvement. (: not unhappy - its just that my role seems no longer of need.

Additional remark about this FieldTest || Test Structuring suboptimal || Also requires some fixing IMHO

The initial issue with my misconception of the test-issue, was based on the following situation:

1. I changed the host_re, to allow for more versatile "localhost" variants. (roughly "localhost" <=> [a-z0-9-]{2-63})
2. (besides other, understandbly failed tests) a test failed, because now value='foo' -> did break the existing tests.
3. this was, because the lazy-scheme feature of the field kicked in, allowing for 'foo' to pass, because it was lazy interprated as "​https://foo"

=> this is an ISSUE!
I never worked close to the lazy-scheming feature, yet tests that are influenced by it fail.

Usually - i would expect the URL-Validator to be tested rigorously, so that the URLFields additional features can be tested more cleanly - and focused.

What i propose:
The URLField "Validation" should be tested in its "accordance with URLValidator", except when it comes to the lazy scheme feature.
Thats, where the URLField would allow for less strict validation.
If it was handled this way, the issue in the FieldTest (point 2.) "would not have failed", because the URLValidator would have rejected it, same as the URLField without lazy scheme or the reverse - if passed with scheme, the URLValidator would have passed it, same as the URLField.

As such - the "lazy scheming" feature would be tested on the field (where it originates), in a way that does not deliver false negatives as it "somehow did" in this situation (because URLValidator was being tested "VIA" URLField)

[Ludwig Kraatz]

Replying to Tim Graham:

If the summary is accurate, it appears to be a duplicate of #25418.

It is not. It is related, thats for sure.
But the summary, how i put it, was more correct: URLValidator not correctly validating URLs

Its more like a super-issue to the one referenced.
It may have started out, same as #25418, but now that i looked deeper into the code, it for sure is way more than just that.

-wontfix- same as -duplicate- seems like not grasping the real issue here.

[Tim Graham]

The current implementation was a design decision. To change the behavior now would need a discussion and a clear consensus. Deprecating URLField and introducing new field types would be rather disruptive, and I don't think it would happen. The fact that #25418 has gone unsolved for 9 years suggests to me that the current behavior is good enough for most use cases. Perhaps the documentation could be enhanced regarding what URLValidator does and does not allow.

By the way, a ticket summary like "URLValidator not correctly validating URLs" is too vague to be useful.

[Ludwig Kraatz]

Replying to Tim Graham:

The current implementation was a design decision. To change the behavior now would need a discussion and a clear consensus. Deprecating URLField and introducing new field types would be rather disruptive, and I don't think it would happen. The fact that #25418 has gone unsolved for 9 years suggests to me that the current behavior is good enough for most use cases. Perhaps the documentation could be enhanced regarding what URLValidator does and does not allow.

By the way, a ticket summary like "URLValidator not correctly validating URLs" is too vague to be useful.

I don't intend this as an offensive last comment - but as the person responsible for this ticket, i see it in my role to respond by defending this issue as resolut as i can - fighting for its right to be taken serious - given, that this is the last time, I'll ever speak of it..

So please, take no offense.
It's purely.. for the sake of quality.

I do see your point, i do.

It is difficult to roll back on mistakes made. Especially when they have been made 'by design'.
But - I still am waiting for a substantial input from the [django community], that could argue and weigh in on this URL-lazyness, to be a reasonable thing to keep as is.

"It is inconvinient to change such a thing" - simply is not good enough. Not for a framework. Not for "Django: The web framework for perfectionists with deadlines" - (I just looked it up... still the same (: )

3 Years of deprecation followed by the actual replacement.. So what. thats life.
Given this issue - more than adequate action. I really don't see your point.

Either, there is a GOOD reason - then present it and everyone in the future can be redirected to that rational and be silenced forever..
Or get constructive and think about how to remedy this unhappy-design-decision.
Go get that consensus. Talk about it in your community. Thats the way to go - i would never ask you to pass out on that step.

I mean.. it could have been as EAASY, as calling it "CustomURL"... Everyone could have benefited.
The whole Lazy-scheme thing... PPPEEERFECT for a CUSTOM-url Field (/Validator)..

Thats the issue with naming things.. it. actually means more than most people make of it.....

Motives || harsh, but meant with a warm smile

Seriously. Either you [django community] find your voice, or i deeply question your motives.
I called out lazyness/comfort/being superficial - referenced it here once more - and am not going to go down that rabbit hole any further, out of respect for the work, all of you [django community] most certainly have put into this great project over the years!

How many years does django exist now? 15+? More? 19! (Looked it up ;). ) I BET - this 'design decision' dates back to the beginning. Or maybe 'changing what has been done in the beginning' - was decided at some point.. because i seriously doubt there being any substantial reason (I allready raised that issue - the lack of presentation of such reason).

But if its not for the quality-of-code and being a "high bar" of (structural) integrity -- i simply don't see the point. NINETEEN YEARS!
With 19 years, i most certainly started to think about how my actions impact the world around me. - Just stating this. -

I wouldn't have put in so much effort for 'some little project'. But django has responsibility, for more than just itself.

too vague? || this part is personal - still not meant to offend anyone

"too vague to be useful" -> kind of meets the criteria of how django's naming conventions seem to go - as well as 'taking "standartized acronyms" serious".
At least when talking about "URLValidator" or "URLField". I don't mean to be rude here - just asking you, to really think about, if what i write is being 'too vague to be useful', when its aimed at critisizing django's implementation which (irrefutably) actually does meet that criteria..
To me - this kind of feels: exactly spot on.

Could not have nailed the title better - even though i did not know it would go to such depth...
I do stand by that title - because there simply is no better way to describe the issue here.

If you feel, it is too vague -- i ask you, from the bottom of my social-responsibility-bucket: do you really understand the issue here?

This issue - is about a complete redesign of this aspect of the django code. Because everything less - would probably be a joke.
As such - spot on.

my last words regarding this matter || this is offensive. To the IETF. And the whole process of standartization

-i do appoligize, i AM sorry - but i still am assigned as responsible for this ticket - and i do take this role very serious-

If thats how the django community wants to ignore and redefine, what a thoughtful process lead/published/?? by IETF has come up with - be my guest.

Be rediculous.

I feel like i finally overstepped.

this was the last statement i made regarding this topic - i ask @Antoliny to unassign me from this ticket, because i no longer feel to be an appropriate representative of this issue.

It is up to the django community to come up with approrpiate ways, to 'deal or not to deal' with this issue.
Going further, my presence does not seem to be of any more use.

I ASK TO BE RELIEVED FROM MY DUTIES

i reopend this issue as a last resort of 'fighting back'. I feel like this is not my place to do - because this is not 'my community' or 'my project'.
But as i said. A measure of last resort.

Keep on the the django spirit! You did great so far (:

[Natalia Bidart]

Hello Ludwig,

Thank you for your time and commitment in describing your view in this ticket. While the URLValidator may not align with your expectations in naming, it is a functional URL validator, and thousands of services rely on its current behavior. Changing this behavior would require a planned deprecation path and clear release notes, which is why your request is better classified as a new feature request. There is a clear and documented​procedure to requesting a new feature, and I kindly ask that you follow it if you wish to pursue this further. Please also note that your project can easily define custom validators to your liking and use those in your model and form fields.

As previously suggested, if you wish to continue discussing your concerns in more detail, you can do so on the Django Forum, where a broader audience can engage with the topic.

That being said, I must note that I find the tone of your messages somewhat confrontational, and at times the point you are trying to make is unclear due to the extensive elaboration. For future discussions in the Django Forum I encourage a more focused and concise approach to ensure your feedback is more easily understood and leads to a more productive conversation.

[Ludwig Kraatz]

I understand that you feel unhappy about my messages.

The reason for my extensive elaboration is easily explained: i dont get your [django representatives] point, I dont feel like you get mine, so I try to do my best to offer ways that might help you see what i mean. Or tell me where i am wrong.

Is it confrontational? Well, it is reactional, to what i was presented so far:

• it was closed right away, without an explanation or trying to understand what it was really about
• it was changed in meaning - reinterpreted, so it is easier to disregard an issue, thats about conformity to standards and consistency in regards to Name vs Functionality
• and as you are doing again right now: it is redefined as a feature request, soley because 'people are used to it' / thats how it would have to be tackled.

Bug vs Feature Request

We seem to have very different understandings of Bugs and Feature Requests.

If i call something 'ABC'. And all it does is 'a' (or XYZ or ABxC), then the code does not do, what is rightfully to be expected, that it would do. Thats what i call a bug.

If i call something 'ABC' and that is what it does. And now i want it to do 'ABCD' or something like 'A[B&/C] - then i would agree, it describes a new feature. Because it would introduce a change into the code that is not needed for the code to consistently do what it claims or suggests to do.

Now i gave plenty of reasons regarding my position, that an URLValidator, that self proclaimed 'validates what looks like an URL' and actively documents that it excludes known and generally accepted and standardized ​file:/// URLs (besides the other shortcommings)- is called ABC, but only delivers a.
And that few people called it a bug in a ticket - does not make a bug, a feature request. Or a bug, less of a bug.
Same goes for difficulties - when dealing with resolving a bug.
Those are no reasons to not accept the severity of an issue - those are things that might influence the way one handles an issue. rightfully, of course.

<this ticket> vs [django] dev process

I completely acknowledge your process and am happy to let you do it your way - all i'm saying is: don't make a bug report a feature request, when you still have not provided an argument, to why this is not a bug.
The only thing you described is, how you would rather treat it as a feature request, due to its nature.
And as i said - i completely understand and support that -- if you decide to handle a bug, that calls for it, by going through a more complex feature request process: i do support that.

But I am here, to report a bug. That is my role - and i take it serious. And it is a bug.
And as long as i am being asssigned i will stand for that.
And i will call it what it is. An URLValidator, not correctly validating URLs.
Even if you try to 'sell' it that way. it is simply wrong. it validates a certain, django approved, subset of URLs. Which is why it should have never been called URLValidator - because that leads to bugs in downstream projects, simply because it has the wrong name.

Thats why I elaborated on the whole project vs framework and social responsibility stuff.

Fact is - you dont even know how many of django dependent platforms use a URLValidator and dont even know they limit their users in this unneccesary non-conformative 'django-special' way.

Bottom line:
If you accept the responsibility of this BUG i presented to you, then feel free to do the django internal process of dealing with it - and if thats via a new internal modernization feature: sure. makes sense to me. if you dont care about it and just want me silent - then ok, leave it as a bug and close it. Im ok with that - not my project, i accept your [django] independece-from-me.

But if you have to use THIS TICKET (because you lack some Trac bug => internal dev mapping i suppose? no criticism, just trying to make sense of it), then do me a solid here, assign yourself to take responsibility of the matter, THEN you can change title, type and whatever you consider right. Thats the only way you're not completly disrespecting my efforts to help you keep [django] code 'in sync with reality' (not meaning this as confrontation -- simply do not know any better way to say it).

sry its been so many words, again - but... if i would understand why my position is so difficult to understand and deal with, trust me - i would have an easier life. but i want things to be done right, because it matters. so i try my best. simple as that, but sometimes messy..

[Natalia Bidart]

Replying to Ludwig Kraatz:

Hello Ludwig. Thank you for your continued input, but please note that the ticket has been carefully read and analyzed, and a decision was made by the Django Fellows. A clear response has already been provided, with a specific resolution (wontfix).

At this point, the only valid next step is to engage with the Django Forum for further discussion. Please refrain from posting in or modifying this ticket, as any further messages may result in your account being suspended.