From 8ebf6acd80e9c6dfbf101ad046c907feebfef2b1 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 29 Feb 2008 13:21:24 -0500 Subject: web commit by http://madduck.myopenid.com/: add analysis based on rfc3986 and suggest a new regexp --- ...ink_for_blog_items_when_filename_contains_a_colon.mdwn | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'doc') diff --git a/doc/bugs/No_link_for_blog_items_when_filename_contains_a_colon.mdwn b/doc/bugs/No_link_for_blog_items_when_filename_contains_a_colon.mdwn index b9b6a23e9..8f320ec3b 100644 --- a/doc/bugs/No_link_for_blog_items_when_filename_contains_a_colon.mdwn +++ b/doc/bugs/No_link_for_blog_items_when_filename_contains_a_colon.mdwn @@ -3,3 +3,18 @@ Since upgrading from Ikiwiki 2.20 to 2.32.3 (from Debian Lenny), I don't get hyp EDIT: I just found that in this wiki under the entry "mailto: links not properly generated in rss/atom feeds" also doesn't have a hyperlink - at least it's not a problem with my config only ;-) [[madduck]]: I traced this down to `htmlscrubber`. If disabled, it works. If enabled, then `$safe_url_regexp` determines the URL unsafe because of the colon and hence removes the `src` attribute. + +Digging into this, I find that [[rfc 3986]] pretty much discourages colons in +filenames: + +> A path segment that contains a colon character (e.g., "this:that") cannot be +> used as the first segment of a relative-path reference, as it would be +> mistaken for a scheme name. Such a segment must be preceded by +> a dot-segment (e.g., "./this:that") to make a relative- path reference. + +on the other hand, with `usedirs`, any link to another page will be prepended +by `../` anyway, so that makes them okay again. + +The solution still seems not to use colons. + +In any case, `htmlscrubber` should get a new regexp, courtesy of dato: `[^:]+($|\/)`. I have tested and verified this. -- cgit v1.2.3