You are here: Foswiki>Tasks Web>Item10905 (17 Dec 2011, GeorgeClark)Edit Attach

Item10905: Wiki [[ syntax does not fully support mailto

Priority: Normal
Current State: Closed
Released In: 1.1.4
Target Release: patch
Applies To: Engine
Component: FoswikiRender
Reported By: VickiBrown
Waiting For:
Last Change By: GeorgeClark

<a href=" feedback &body=Internal Docs Feedback: ">Test 1</a>


[[ feedback &body=Internal Docs Feedback: ][Test 2]]

Using HTML href syntax, the mailto body parameter is supported and the desired text is placed in the draft email message.

Using Wiki [[ syntax, only the subject parameter is recognized.

Try it

-- VickiBrown - 20 Jun 2011

Some definite strangeness here. The ampersand is encoded as an entity, both in email and topic links,;body=qqqq with spaces&body=qqqq
mailto:%WIKIWEBMASTER%?subject=asdf with spaces&body=qqqq

Item10905 (ampersand delimited)

Item10905 (semicolon delimited)

Item10905 (embedded Space)

Item10905 (embedded plus)

Displayed URL parameters
  • Action: missing
  • blah: missing

Actually according to W3C, the ampersand in the URL must be encoded. See

So it appears that the target of the mailto doesn't process the escaped uri correctly. The mailers I've tested don't seem to correctly handle semi-colon correctly either.

  • Gmail webmail - appended body to Subject
  • Yahoo webmail - Appended both Subject and body to the To: field

Although it's not giving the desired results I suspect that Foswiki is handling this correctly at least per the standards.

-- GeorgeClark - 20 Jun 2011

Another issue is that spaces should be being encoded as plus-signs. It appears space is terminating the query string.

-- GeorgeClark - 20 Jun 2011

unfortunately, if a user notices that href works as "expected" and Foswiki doesn't, the user really isn;t going to care if Foswiki is "technically correct" per the standards. All the user will see is that href works and Foswiki doesn;t.

-- VickiBrown - 21 Jun 2011

Agreed. Looking at the generated source of the page, the links appear to be double encoded. Some of the coding is done elsewhere in the rendering loop, not in the [[ link expansion. I don't have much of an idea currently how to address it. Here are the above test links interleaved with the rendered results:

<a href="mailto&#58;webmaster&#64;foswiki&#46;org&#63;subject&#61;asdf&#38;amp&#59;body&#61;qqqq">mailto&#58;webmaster&#64;foswiki&#46;org&#63;subject&#61;asdf&#38;amp&#59;body&#61;qqqq</a>

<a href="mailto&#58;webmaster&#64;foswiki&#46;org&#63;subject&#61;asdf&#59;body&#61;qqqq">mailto&#58;webmaster&#64;foswiki&#46;org&#63;subject&#61;asdf&#59;body&#61;qqqq</a>

[[mailto:%WIKIWEBMASTER%?subject=asdf with spaces&body=qqqq]]   <verbatim class="tml">mailto:%WIKIWEBMASTER%?subject=asdf with spaces&body=qqqq</verbatim>
<a href="mailto&#58;webmaster&#64;foswiki&#46;org&#63;subject&#61;asdf">with spaces&amp;body=qqqq</a>   <pre>mailto:&#37;WIKIWEBMASTER&#37;?subject&#61;asdf with spaces&#38;body&#61;qqqq</pre>

[[%TOPIC%?action=yes&blah=two]]   (ampersand delimited)
<a href="/Tasks/Item10905?action=yes&amp;amp;blah=two" class="foswikiCurrentTopicLink">Item10905</a>   (ampersand delimited)

[[%TOPIC%?action=yes;blah=two]]   (semicolon delimited)
<a href="/Tasks/Item10905?action=yes;blah=two" class="foswikiCurrentTopicLink">Item10905</a>   (semicolon delimited)

[[%TOPIC%?action=yes please;blah=two]]   (embedded Space)
<a href="/Tasks/Item10905?action=yes please;blah=two" class="foswikiCurrentTopicLink">Item10905</a>   (embedded Space)

[[%TOPIC%?action=yes+please;blah=two]]   (embedded plus)
<a href="/Tasks/Item10905?action=yes+please;blah=two" class="foswikiCurrentTopicLink">Item10905</a>   (embedded plus)

-- GeorgeClark - 21 Jun 2011

Babar pointed out that rendering of mailto: links is done prior to rendering of the square-bracket links. So they have already been processed once and encoded before the [[ link is processed. Test a direct mailto link using encoded spaces.

-- GeorgeClark - 21 Jun 2011

Just my 2 cents, but this should work: Result: it doesn't, as the pattern stops at the ?. Maybe we should add a ? in the regexp?

-- OlivierRaginel - 21 Jun 2011

Multiple issues:
  • The link is truncated at the first space. This is due to support for legacy [![URL anchor text]] format. Fix is to make mailto: links an exception to that legacy format.
  • The double encoding is can be worked around by disabling {Spam}{HideUserDetails} in the configuration. The code has a big warning to not touch that double-encoding. Need to understand why.

Kenneth, Crawford. I'm setting this task waiting for your feedback. The code that does the double-encoding was removed by CDot and reverted back in by Kenneth back in 2007. But it makes a real hash of the email addresses, so I don't understand why it's needed. It's in routine _externalLink

        if ( $Foswiki::cfg{AntiSpam}{HideUserDetails} ) {
          # Much harder obfuscation scheme. For link text we only encode '@'
          # See also
          # and
          # before touching this
            $url =~ s/(\W)/'&#'.ord($1).';'/ge;
            if ($text) {
                $text =~ s/\@/'&#'.ord('@').';'/ge;

-- GeorgeClark - 21 Jun 2011

The fix for embedded spaces breaks backwards compatibility for legacy style links, [[ This is the link text]] works and will be broken by distro:3dfecc57a739. Possible solutions:
  • Don't fix - require + encoding for embedded spaces - not very friendly
  • Add mailto: exception to the legacy format which will break old style mailto links
  • Deprecate legacy [[ format, and make it a configuration parameter. Document that backwards compat means embedded spaces in the query string must be encoded as %20

-- GeorgeClark - 22 Jun 2011

See DeprecateUndocumentedSqBracketLinkFormat

-- GeorgeClark - 23 Jun 2011

Crawford suggested a simple workaround - if the URL component contains a ?, then the presence of a query string is indicated, and we should not allow space to be a delimiter. This preserves the legacy format and allows spaces in the query string.

-- GeorgeClark - 23 Jun 2011
Topic revision: r17 - 17 Dec 2011, GeorgeClark
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy