Skip to content

[Validator] Accept underscores in the URL validator, as the URL will load #32522

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Sep 27, 2019

Conversation

battye
Copy link
Contributor

@battye battye commented Jul 12, 2019

Q A
Branch? 3.4
Bug fix? yes
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets #32506 #10467
License MIT
Doc PR -

As @javiereguiluz mentioned, regardless of convention a URL with an underscore in it will load perfectly fine - so in that respect it must be valid.

nicolas-grekas
nicolas-grekas previously approved these changes Jul 13, 2019
@nicolas-grekas nicolas-grekas dismissed their stale review July 18, 2019 06:51

Review found that this should not be allowed in the root domain name.

@battye
Copy link
Contributor Author

battye commented Jul 18, 2019

One important thing to consider is that it will be quite difficult to determine what constitutes a subdomain and what constitutes a root domain. Consider google.com vs google.co.uk for example. Using regex we can't assume that the second to last component is the root domain.

Given that this class is UrlValidator and not a domain validator, I think the solution in this PR is likely to produce less false positives to users like @kptLucek than it will if it's left the way it is.

['http://localhost/'],
['http://myhost123/'],

As we already validate hostnames as true, and goog_le.com is a valid hostname (as the hosts file example shows), I don't even think it is a false positive anyway.

Maybe a new domain validator would be a good feature though? I think having a domain validator is really the only way we can solve this problem in its entirety though, as a regex-only solution looks to be unfeasible. With a domain validator, we could maintain a list of known TLDs and fixed second-level domains. Perhaps it could allow for an integration with the URL validator, with an option of specifying a URL as belonging to a hostname or domain name before validating.

Copy link
Member

@nicolas-grekas nicolas-grekas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me, this is pragmatic enough.

@nicolas-grekas nicolas-grekas force-pushed the bugfix/url-validator-underscore branch from 07cbe94 to c9c7a11 Compare September 27, 2019 06:54
@fabpot
Copy link
Member

fabpot commented Sep 27, 2019

Thank you @battye.

fabpot added a commit that referenced this pull request Sep 27, 2019
…e URL will load (battye)

This PR was merged into the 3.4 branch.

Discussion
----------

[Validator] Accept underscores in the URL validator, as the URL will load

| Q             | A
| ------------- | ---
| Branch?       | 3.4
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #32506
| License       | MIT
| Doc PR        | -

As @javiereguiluz mentioned, regardless of convention a URL with an underscore in it will load perfectly fine - so in that respect it must be valid.

Commits
-------

c9c7a11 [Validator] Accept underscores in the URL validator as the URL will resolve correctly
@fabpot fabpot merged commit c9c7a11 into symfony:3.4 Sep 27, 2019
@battye battye deleted the bugfix/url-validator-underscore branch September 27, 2019 11:59
@dunglas
Copy link
Member

dunglas commented Sep 29, 2019

It should be an opt-in option. Unlike domain names, hostnames (and so URLs) cannot contain underscores (RFC 1123, section 2.1).

While it’s ok to support this for compatibility with non-standard clients, but it shouldn’t be the default.

@dunglas
Copy link
Member

dunglas commented Sep 29, 2019

Also, PHP has a built-in domain name validator (you’re right, a domain name cannot be validated with a regex).

@fabpot fabpot mentioned this pull request Oct 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants