Item12050: UNC Links are corrupted by render when they contain embedded spaces
Current State: Closed
Released In: 2.0.0
Target Release: major
Reported on IRC by an anonymous user. (see http://irclogs.foswiki.org/bin/irclogger_log/foswiki?date=2012-08-23,Thu&sel=257#l253
- 1 - Link with embedded spaces pasted into a squab link. The space is interpreted as the deprecated space delimited
[[link title]] format. Wikiwords in the title part are rendered, and generally it's completely corrupted. We should probably encode the spaces automatically when rendering as a link, and not apply the deprecated space delimited format to file: style links.
[[file:///\\somesite.local\data\somesite\Shared Docs\Software Projects\Soft AAbBC\system_design\imaging\AAbBC Imaging Glossary.doc]]
- 2 - Manually encoding spaces as %20 in the UNC, the link is rendered correctly.
- 3 - Link with embedded spaces pasted into a href link. Even though contained within the quoted string, the rendering is corrupted. However WysiwygPlugin correctly converts this link into case 2. resulting in an encoded link in the squab. So after an edit/save cycle with wysiwyg, the link renders correctly. We should not break the quoted string on the space, and should auto-encode the spaces so the user doesn't have to.
<a href="file:///\\somesite.local\data\somesite\Shared Docs\Software Projects\Soft AAbBC\system_design\imaging\AAbBC Imaging Glossary.doc"> some doc</a>
- 4 - Correctly encoded link renders correctly
<a href="file:///\\somesite.local\data\somesite\Shared%20Docs\Software%20Projects\Soft%20AAbBC\system_design\imaging\AAbBC%20Imaging%20Glossary.doc"> another doc</a>
Confirmed identical behavior on trunk and release11 branches.
- 24 Aug 2012
for more details.
- 24 Aug 2012
Defering to 1.2.
- 02 Nov 2012
The embedded space issue is because there is an old deprecated link format where space delimits between the url and the text. I suspect that the only way to support embedded spaces in links is to eliminate the legacy format. From a comment in Render.pm:
# Legacy case of '[[URL anchor display text]]' link
- 19 Jun 2014
Well I thought that this format was deprecated, but it it's not documented as such. See TextFormattingRules
You can also write
[[http://yahoo.com Yahoo home page]] as an easier way of doing external links with descriptive text for the link, such as http://yahoo.com/ Yahoo home page.
I've got a patch available that disables the legacy format so that spaces can be used in links. Unfortunately this probably needs a proposal.
- 20 Jun 2014
Another option would be to test for a file://
style link and disable the space delimiter. This is also done for any link containing a ? indicating that there might be url parameters. That would let the legacy format remain. See the rejected proposal: DeprecateUndocumentedSqBracketLinkFormat
- 20 Jun 2014
does make sense ... as does all the other tests for special cases. And tomorrow we will add even more tests for more special cases where the behavior should diverge.
I've got the feeling that now
we are at a point to hold on and stop this. A deprecation process finally has to follow up on removing a feature at some point. Even more so when it hinders further advance.
So instead of adding YASC (yet another special case), I'd rather prefer to simplify
things by removing long deprecated non-documented features. Only then will any further modifications on parsing square bracket links make sense.
We should make it a habit to remove deprecated features on dot oh releases.
I am afraid there are so many deprecated features that long should be executed upon. We really should list them all including dates they were created and planned releases their referring feature is about to be removed, maybe a patch contrib to bring it back for the real desperate cases.
- 20 Jun 2014
So resolution of this will be to strip out the space delimited square bracket format:
[[http://yahoo.com Yahoo home page]]
- Remove from Render.pm
- Remove from documentation
- Remove from WysiwygPlugin
- 02 Aug 2014
Also fixes Item12824