Parentheses in a URL break the link

ChrisH

When a URL with parentheses () is added to a post, it breaks the link. Like this example:

http://developer.android.com/reference/android/location/LocationManager.html#requestLocationUpdates(java.lang.String, long, float, android.location.LocationListener)

Please note that according to RFC3986, parentheses in URLs are perfectly acceptable. So this seems to be a parser bug in Vanilla Forums.

hgtonight

The issue is with the input formatters then?

Using the "proper" markdown yields the same issue: [Pretty Link](http://developer.android.com/reference/android/location/LocationManager.html#requestLocationUpdates(java.lang.String, long, float, android.location.LocationListener))

An aside: since when are spaces supported in URLs?

What version of Vanilla did you test on?

Tama

oops delete this please

ChrisH

@hgtonight - I noticed it in the Xamarin forums as a user. It is a bit annoying and pops up often, because Google's documentation systems use parentheses in URL fragments everywhere.

You're right about the spaces - that's just Google not understanding how URLs work :-P

hgtonight

For reference, that site appears to be running a hosted version of 2.1a40.

I would suggest sending the admin of the site a notice to send in a support request for their forum hosting.

x00

http://developer.android.com/reference/android/location/LocationManager.html#requestLocationUpdates(java.lang.String,%20long,%20float,%20android.location.LocationListener)

[http://developer.android.com/reference/android/location/LocationManager.html#requestLocationUpdates\(java.lang.String,%20long,%20float,%20android.location.LocationListener\)](http://developer.android.com/reference/android/location/LocationManager.html#requestLocationUpdates\(java.lang.String,%20long,%20float,%20android.location.LocationListener\))

Pretty Url

[Pretty Url](http://developer.android.com/reference/android/location/LocationManager.html#requestLocationUpdates\(java.lang.String,%20long,%20float,%20android.location.LocationListener\))

x00

note %20 for space and the escaping \( and \)

ChrisH

I already filed a bug report on developer.google.com, asking them to start encoding their URLs. But the issue with the parentheses is on the side of VanillaForums - they are legal characters and should not have to be encoded.

I also posted a message about this on the Xamarin Forums, but I was hoping that directly commenting on VanillaForums HQ might be more expedient

ChrisH

Note - I am fully aware of Markdown syntax and URL encoding. Just pointing out what seems to be a bug in VanillaForums.

In fact I have been in the same shoes, with a Markdown parser I wrote myself, where I had to deal with parentheses in URLs in particular. In defense of VanillaForums, not many systems accept URL parentheses.

x00

???

You still have to escape the parenthesis in markdown. It works fine.

You said you dealt with it in your parser, but in fact in markdown links they should escaped. With an expansive match system, this could introduce worse bugs. Stick to escaping.

You could ask that the button bar include the escaping, but it is not a major priority I would have thought.

Spaces need to be encoded.

You are talking about auto linking, it is not going to be perfect.

x00

Quite honestly if someone give me a link like that they might as well have use an url shorter. That is the best solution for cases such as this.

If you people are using that site often create plugin addressing this making your own autolinks

http://developer.android.com/reference/android/location/LocationManager.html#requestLocationUpdates(java.lang.String, long, float, android.location.LocationListener)

the above is rawurlencoded after the #

x00

http://www.utoronto.ca/web/HTMLdocs/NewHTML/name_token.html

http://www.w3.org/TR/html4/types.html#type-cdata

ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").

in other words the named anchors are NOT legal, even if the url contains valid characters.

it is also obsolete in htm5

ChrisH

Did you read the actual RFC? That is the only authoritive reference, and you will note that the W3 pages also simply refer to the RFCs.

Named anchors do not factor into it. Those are just one of the many use cases for URL fragments.

And yes, a valid workaround and probably a better solution in this case is to use a URL shortener. But they are not a silver bullet - a meaningful original URL used in a non-space-limited system is preferable if possible.

Again, the issue is partly with Google including whitespace in their URLs - hence the bug report there. But the parentheses should ideally be dealt with in VanillaForums, because they are allowed as per spec.

I do say ideally. Again, not many systems actually deal with this properly, and agreed, URLs are surprisingly hard, auto-detecting them even more so. Doing it using regular expressions is a nightmare.

So, I'm not making a big deal out of it at all. Simply noting that this could be improved. I did do so myself.

x00

Named anchors do not factor into it

They do in this case. There for you have to take into consideration both meaning that after # you cannot have these character if pointing to a web page.

Of course standard are to be taken with a pinch of salt even google knows that. Sometime you have to bend the rule round the ends.

The problem with many of these standards committees is they think first, experiment later. Think how long the spent on xml and derivatives like xhtml. that time as almost entirely a waste of time, that they could have been spending on the likes of html5. It was only thanks to others that got off the ground.

One of the issues with the markdown filter for vf, is it compound filter of markdown, and htmLawed. This means it has a but of quirks an inconsistencies. Also the markdown is not as versatile as github flavoured markdown.

however htmLawed is there to strip out nasties.

---

If your users are making use of that site often, then specific detection, would make sense becuase, you could get cleaner more meaningful link that actually work.