HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Parentheses in a URL break the link

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.

Comments

  • hgtonighthgtonight ∞ · New Moderator
    edited June 2013

    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?

    Search first

    Check out the Documentation! We are always looking for new content and pull requests.

    Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.

  • TamaTama United Kingdom ✭✭✭
    edited June 2013

    oops delete this please

    There was an error rendering this rich post.

  • @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

  • hgtonighthgtonight ∞ · New Moderator
    edited June 2013

    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.

    Search first

    Check out the Documentation! We are always looking for new content and pull requests.

    Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.

  • x00x00 MVP
    edited June 2013

    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\))
    

    grep is your friend.

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

    grep is your friend.

  • 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 :)

  • 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.

  • x00x00 MVP
    edited June 2013

    ???

    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.

    grep is your friend.

  • x00x00 MVP
    edited June 2013

    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 #

    grep is your friend.

  • 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

    grep is your friend.

  • 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.

  • 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.

    grep is your friend.

Sign In or Register to comment.