70

I was trying to post something similar over on Super User:

… [images](http://www.mediawiki.org/wiki/Manual:$wgAllowExternalImages)?

However, the comment was rendered as:

<a href="http://www.mediawiki.org/wiki/Manual:wgAllowExternalImages">...</a>

The $ was stripped without further notice, and if I hadn't checked, I wouldn't have seen that the link was broken. RFC 3986 says that this is a valid URL character. Therefore, please allow it.

4
  • 10
    Trying to reproduce. (See the broken link?)
    – slhck
    Jan 13, 2012 at 10:49
  • 2
    trying workarounds - 1) posting the link as-is: mediawiki.org/wiki/Manual:$wgAllowExternalImages and 2) posting as code http://www.mediawiki.org/wiki/Manual:$wgAllowExternalImages. Test result: workarounds available
    – gnat
    Jan 13, 2012 at 10:56
  • @gnat Interesting. My workaround was to URL-shorten it :P
    – slhck
    Jan 13, 2012 at 12:08
  • 14
    What about percent-escapes? Works!
    – celtschk
    Jan 13, 2012 at 14:44

4 Answers 4

5

This will be working after the next build.

See this answer of mine for details.

5

If possible, $ should not be removed but just left alone.

See the comments on my answer and check out his answer, it appears that this character is valid.

--

If not possible, $ should be replaced by %24.

In practice, this would not break the link (at least for http links).

This replacement might not be that comform to the standard, but at least it works better...

4
  • I upvoted this before realizing that, actually, this advice technically violates the URI spec (RFC 3986 section 2.2), which explicitly says that $ (and the other "reserved" characters) are allowed in URIs and may not be percent-encoded without potentially changing the meaning of the URI. Mar 14, 2012 at 13:57
  • @IlmariKaronen: However, later RFCs can amend earlier RFCs. And I don't see how potentially changing the meaning is happening here, because you still end up at the same resource... Mar 14, 2012 at 14:02
  • 1
    They can, but I'm not aware of any that would, in this case. (In particular, AFAICT, RFC 3987 doesn't; it uses the exact same set of "reserved" characters with the same meaning.) As for potentially changing the meaning, the point is that $ and %24 are not equivalent in URIs (or IRIs): there could be URI schemes that use $ as a delimiter, like e.g. & is used as one in HTTP query strings. Yes, in practice, replacing $ with %24 is unlikely to break anything, at least if only applied to http URIs, but it's still technically the wrong thing to do. Mar 14, 2012 at 14:16
  • 1
    @IlmariKaronen: Amended my answer. Mar 14, 2012 at 14:20
3

Posting this to contrast with the other answers:

The $ character should be allowed in links, and should not be mangled in any way.

According to RFC 3986, section 2.2, all of the following "reserved" characters are allowed in URIs:

gen-delims  = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims  = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="

The reason these characters are called "reserved" is that they may be used as delimeters between URI components or subcomponents (as e.g. & is used to delimit parameters in http URI query strings), and thus are not generally considered equivalent to their percent-encoded forms.

I do realize that not all of these characters can or should always be treated as part of an adjacent URL by the StackExchange parser, since some of them are either used as delimiters in Markdown syntax, or are common punctuation characters that are frequently appended to URLs included in English text. However, $ does not seem to fall into either of these categories, and thus there should be no reason not to just treat it as a normal valid URL character.

In particular, parsing $ as part of an URL but then stripping it out completely, as the OP describes as happening in comments, is just plain broken. Whatever you do, don't do that.

Ps. The same set of reserved characters is also allowed in IRIs by RFC 3987, section 2.2.

1

This should not be allowed without consideration for RFC 3987

The W3C is actively promoting the switch to IRI's which have syntactic restrictions based on the Universal Character Set which covers things like currency

ADDITIONAL EDIT IN RESPONSE TO COMMENT

I am not going to copy the spec, but the important sections are 2.2, 4.1 and 6.1

It also cites RFC 3491 for "unwise" characters

7
  • What are these syntactic restrictions, exactly?
    – slhck
    Feb 9, 2012 at 14:01
  • -1, I don't see $ in any of the tables listed for unwise characters in appendix C of RFC3454, nor any reference to it in 2.2, 4.1, or sections 6.1 of RFC3987...
    – user7116
    Feb 9, 2012 at 15:52
  • The point was that you should be considering this in relation to the IRI RFC and not the URI RFC. I take it when you read the "unwise" characters you specifically qualified them against RFC3454 (ietf.org/rfc/rfc3454.txt) Feb 9, 2012 at 16:21
  • 1
    @WilliamGreenly: I'm saying I find no reference to currency or $ (nor its code-point) in any of the RFCs you've referenced.
    – user7116
    Feb 13, 2012 at 16:05
  • Also, can you please summarize in one sentence what you want? "This should not be allowed" in the sense of not allowing $ to appear? It's a URL I want to post. It shows in my browser's URL bar, why shouldn't I be able to link it? Well, I can, but it gets silently stripped, which produces a broken link. That's the bug here.
    – slhck
    Feb 14, 2012 at 10:26
  • 1
    -1 for lack of clarity. If you just literally mean that RFC 3987 should be kept in mind when writing URL parsers, then, yes, that's of course true. However, if you're implying that something in that RFC, or any of the others it cites, somehow forbids or advises against the use of $ in the path portion of URIs / IRIs, could you please explain exactly where and how you think it says so? Mar 14, 2012 at 13:46
  • In fact, the only mention of $ I can find in RFC 3987 is in section 2.2, in the BNF grammar fragment marked as "same as those in [RFC3986]", which includes $ in the sub-delims production, whose characters are explicitly allowed in the path portion of IRIs. (See the ipath-*, isegment-* and ipchar productions above.) Mar 14, 2012 at 14:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .