Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 158 Stack Exchange communities.

What is meta?
Here's how it works:
  1. Any Stack Exchange user can ask a question
  2. The community provides support, votes on ideas, and reports bugs
  3. Your voice helps shape the way Stack Exchange operates

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

… [images]($wgAllowExternalImages)?

However, the comment was rendered as:

<a href="">...</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.

share|improve this question
Trying to reproduce. (See the broken link?) – slhck Jan 13 '12 at 10:49
trying workarounds - 1) posting the link as-is:$wgAllowExternalImages and 2) posting as code$wgAllowExternalImages. Test result: workarounds available – gnat Jan 13 '12 at 10:56
@gnat Interesting. My workaround was to URL-shorten it :P – slhck Jan 13 '12 at 12:08
What about percent-escapes? Works! – celtschk Jan 13 '12 at 14:44
up vote 5 down vote accepted

This will be working after the next build.

See this answer of mine for details.

share|improve this answer

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

share|improve this answer
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. – Ilmari Karonen Mar 14 '12 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... – Tom Wijsman Mar 14 '12 at 14:02
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. – Ilmari Karonen Mar 14 '12 at 14:16
@IlmariKaronen: Amended my answer. – Tom Wijsman Mar 14 '12 at 14:20

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.

share|improve this answer

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


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

share|improve this answer
What are these syntactic restrictions, exactly? – slhck Feb 9 '12 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 '12 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 ( – William Greenly Feb 9 '12 at 16:21
@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 '12 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 '12 at 10:26
-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? – Ilmari Karonen Mar 14 '12 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.) – Ilmari Karonen Mar 14 '12 at 14:03

You must log in to answer this question.

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