Spaces in URL cause link_validate_url() to fail

Hmmm. That sounds like a decent thing to do. I'll try to fit it in there.

Of course, if you can roll a patch of that change, that would be a nice thing to share back to the project, and make it easier to include! Give it a try!

I ran into this problem too.

I'm not sure where line 686 was when you first posted, Ogredude, but, since you use $text, I'd guess it's in link_validate_url().

The attached patch works for my test case of a normal URL with some spaces in it.

I think, though, that the str_replace() probably belongs elsewhere in the function, (if not in another function entirely.) It should probably only apply to $external_pattern links, right? And then only in $end...

Well, here's for starters.

Okay, I've fixed this by changing the query regex to accept spaces in that section. I don't think spaces are valid in any other part of the url, and really the query is pushing it.

This problem goes beyond the space character. People put things in URLs that they shouldn't, then users copy and paste them into Drupal forms, and there is a whole set of characters where they are okay if encoded but not if left blank.

Would it be better to urlencode() the link before validation/display instead of expanding the regular expression?

For example, I have a problem with { and }. Someone puts these in URLs even though they should use %7B and %7D instead, which are valid. I had submitted the validation-circumvention patch at http://drupal.org/node/323879 but agree that I don't want any old person putting any old text in a link field.

Is there any interest in a patch that did this?

The problem here is not in the specifics of what is a legal URL as in the RFCs. The issue is that general users will copy a link out of their browser address bar, which copies it without url encoding. They then paste it into the link field which throws a validation error due to the spaces.

Here's the URL I am looking at:

http://www.fifa.asn.au/files/pdf/publications/Cracking the Nutrient Code optimized.pdf#page=35

I think its a valid use case as it's not fair to expect general users to understand url escaping.

For now I'm applying jeff's patch in #2. All those regex's are a bit scary for me :)

Cheers,
Sam.

Dear followers of this issue: please read the project page info of link module for further validation issues. There is already an issue to collect and discuss all possible validation scenarios in general. That's why I will mark this one here as duplicate. I need all concentration inside the ONE and only discussion to move forward. After a D7 implementation we will provide a D6 backport.

Explanation: There are too many corner cases and validation wishes of users to implement them all serially one after the other. We would have a 40 lines cluttered settings form for validation methods, conflicting with each other randomly. I think, the right way is to find a maybe more complex but all embracing new configuration method, which lets the admin better decide, how and when to validate the url. Including a good description which helps to set it up. This will surely lead to a new branch

When I use "%20" in the url it's rendered as "%2520"

so I am unable to use a link with space in URL

1. doesn't allow me to enter url with space(validation error)
2. url with %20 is rendered wrong and hence the link is broken.

Yes, the space is usually encoded to "%20" though. Any parameters that pass to a URL should be encoded, simply for safety reasons. URLs are defined in RFC 3986, though other RFCs are relevant as well but RFC 1738 is obsolete.

URLs: They may not have spaces in them, along with many other characters. Since those forbidden characters often need to be represented somehow, there is a scheme for encoding them into a URL by translating them to their ASCII hexadecimal equivalent with a "%" prefix.

Most programming languages/platforms provide functions for encoding and decoding URLs, though they may not properly adhere to the RFC standards. For example, I know that PHP does not.

For further discussion please read comment #7 carefully. thanks.

#1318938: An all-embracing attempt for URL validation and Input / Output Form Filtering