Escaped version

The following [link][1] does not work, neither does <a href="http://web.archive.org/web/20121130000728/http://www.google.com/">this</a>.

[1]: http://web.archive.org/web/20121130000728/http://www.google.com/

Formatted version

The following link does not work, neither does this.

(The screenshot due to the above text now displays correctly after the fix was applied.) Enter image description here

  • It looks fine in the edit preview, though. – nhahtdh Jan 28 '13 at 1:00
  • Yea, that's the weirdest part. – Scott Chamberlain Jan 28 '13 at 1:03
  • 1
    I don't think it is weird, if the edit preview is generated with JS. The main post is converted from Markdown to HTML on server. – nhahtdh Jan 28 '13 at 1:04
  • 5
    Funny, it seems to work in comments. – Richard J. Ross III Jan 28 '13 at 1:16
  • @nhahtdh Differences between live preview and actual post formatting are by design – Daniel Beck Jan 28 '13 at 6:34
  • 4
    @DanielBeck No, they're not, not at this level. Things like this should be identical. – balpha Jan 28 '13 at 7:14
  • Hmm, sorry, I figured adding a screenshot for future reference would be nice, but it seems that the edit also made the HTML for this very question work nicely. However, @balpha, the problem still exists with URLs in query parameters? See Link working in preview but not on post. – Arjan Apr 6 '13 at 12:04
  • @Arjan That's a mainly unrelated issue, but yeah, fixing. Regarding "screenshot for future reference" -- meh. Who cares about this in the future? – balpha Apr 6 '13 at 12:24
  • If it doesn't come back, then probably nobody, @balpha :-) (Even if it does come back, if I were developing this, then I'd rather have the exact HTML output instead of a screen capture, but this Arjan guy is a bit lazy ;-)) – Arjan Apr 6 '13 at 12:32

Discourse on regular expressions ahead. If you don't care for such a thing, just know that this is fixed in the next build.

Ah yes, the neverending story of link-within-a-link creation. We have several unpretty hacks in place to prevent this in multiple areas. Could just add another one for this new case.

There's a few ways of fixing it, but all this escaping and encoding problem characters is getting a bit messy, so I'm not sure what the best approach is.

So true, Tim.

It looks fine in the edit preview, though.

Hmm, you're right, nhahtdh. Now why would that be?

The reason for this is what is usually a deficiency in JavaScript regular expressions: They don't support lookbehinds.

I say "usually", because in this case, this gave me the idea for a fix that's much cleaner than doing yet another "encoding problem characters" step.

So the change to allow auto-linking of URLs preceded by a non-word character and neither by =" nor by < (which, despite all the havoc I've created with it so far, I still consider a good change), was implemented differently in the server-side Markdown version and in the client-side version. .NET regexes do support lookbehinds, so on the server it was as simple as


For the JavaScript version, I had to simulate a negative lookbehind by using


and by not handling a match if this group was matched.

Simulating lookbehinds this way has a disadvantage: The match also consumes these preceding characters; it's not a zero-width assertion. That's not a problem in this case though.

There's a second difference though. Imagine the following:

<a href="http://foo.com/http://bar.com">
       ^ ^              ^            ^
       A B              C            D

When walking through this string, the server-side version doesn't match at B, because of the lookbehind. It continues on through the string, and finds a match at C, which is not preceded by =", and auto-links the part between C and D. Not what we like.

The JavaScript version on the other hand matches the full thing from A to D. It leaves it unchanged, because the (<|=")? group was matched, but the important thing is: This match consumes the whole part from A to D. And thus the inner link from C to D is never touched.

From the next build on, the server-side version does the same thing as the client-side version. And I would never have believed I'd one day say "I'm glad that JavaScript regular expressions don't support lookbehinds".

  • In the 2 regex examples, shouldn't ="" part be =" as raw regex (regex without string escaping or escaping due to delimiters)? – nhahtdh Jan 28 '13 at 13:17
  • @nhahtdh Ah yeah, thanks. Copy&paste error. – balpha Jan 28 '13 at 13:21

I suspect that the recent Markdown breakdown also broke this feature.

I've changed step 2 to require a URL to be preceded by a non-word character and neither by =" nor by < to be eligible for auto-linking.

Judging from the fact that the broken HTML is only showing the http://www.google.com/ part, I'd say that the "fixed" Step 2 there is causing angled brackets to be placed in spots where they do not belong again, creating something like this:


After all, a / is not a forbidden character. ;P

  • Good find, thanks! I put a link to this question as a comment to the dev so they can add it to the unit test too. – Scott Chamberlain Jan 28 '13 at 6:39
  • Yeah, that's the issue. There's a few ways of fixing it, but all this escaping and encoding problem characters is getting a bit messy, so I'm not sure what the best approach is. – Tim Stone Jan 28 '13 at 6:40

You must log in to answer this question.

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