Last modified: 2011-03-13 18:04:50 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T7720, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 5720 - Parameters to {{fullurl}} et al. should be URL-encoded
Parameters to {{fullurl}} et al. should be URL-encoded
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
All All
: Lowest enhancement with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2006-04-26 03:21 UTC by
Modified: 2011-03-13 18:04 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description 2006-04-26 03:21:51 UTC
Parameters to {{fullurl:}} are not URL encoded, and this can lead to issues with
spaces in parameter names. For example:

[{{fullurl:Special:Log/block|page=User:Locke Cole}} link]


"http://server/wiki/Special:Log/block?page=User:Locke Cole"

This space in "Locke Cole" is treated as a space in the link syntax ([<url>
<link title>]). So, after {{fullurl:}} performs it's magic, we end up with this:

[http://server/wiki/Special:Log/block?page=User:Locke Cole link]

Which renders as:

"Cole link"

With the anchor tag pointing to:


Note: {{fullurle}}, {{localurl}} and {{localurle}} would also need to be changed
if solution #1 were chosen.
Comment 1 2006-04-26 03:22:10 UTC
As I see it, there are two possible solutions to this:

1) URL encode parameters.
2) Provide a set of new magic words to allow editors to URL encode/decode as
necessary ({{urlencode:<string>}} and {{urldecode:<string>}}).

I'm leary of solution #1 because of possible unintended side effects, but at the
same time, solution #2 would be unnecessary bloat if solution #1 could work.
Comment 2 lɛʁi לערי ריינהארט 2006-04-26 10:54:54 UTC
Bug 839: method to URL-escape arbitrary text (e.g. the name of some other page)
Comment 3 omniplex 2006-04-26 22:24:44 UTC
839 appears to be more general. Just in case:

The "normal" way to deal with spaces is %20,
that also works for [[google:query strings]].

Google also offers "+", where Wikipedia wants
"_" (underscore). We probably only want "_" (?)
Comment 4 lɛʁi לערי ריינהארט 2006-04-26 22:39:19 UTC
(In reply to comment #3)
> The "normal" way to deal with spaces is %20,
> that also works for [[google:query strings]].
> Google also offers "+", where Wikipedia wants
> "_" (underscore). We probably only want "_" (?)

see Bug 707: Google search with [[Google:search term]]
Comment 5 omniplex 2006-04-28 01:55:40 UTC
[[mediazilla:707]] is more general, and it's Latin-1 part is
probably obsolete, RFC 3987 wasn't published at this time (?)

But fullurl: / fullurle: / localurl: / localurle: are straight
forward: CTL, SP, '"', "<", ">", "\", "^", "`", "{", "|", "}",
and "#" can't occur in the query part of an URL, they have to
be percent encoded. Replacing %20 for all spaces should do it.
Comment 6 Rob Church 2006-05-17 15:36:59 UTC
Note: We now have {{urlencode}}.
Comment 7 omniplex 2006-05-18 13:43:18 UTC
Nice, but it uses "+" for spaces, not the "universal" (in my parallel universe)
"%20". On [[m:Help:Variable]] (end of first section) I've replaced a convoluted
workaround by urlencode:, and for that example "+" worked. It should also work
for google queries. Is "+" really okay for Wikipedia everywhere?
Comment 8 Minh Nguyễn 2006-05-18 19:57:54 UTC
Nope. That's because "+" is a valid character in MediaWiki page titles now
([[C++]] for example). The escape sequence "%20" would work for MediaWiki pages,
and I think it'd work for Google queries too.
Comment 9 Daniel Kinzler 2006-05-18 20:32:18 UTC
using "+" to escape space is aprt of the URL and HTTP RFCs and should thus work
universally. I just checked, it also works in MediaWikis external link syntax
(both "boxed" and "free"). It should also work in normal wiki links, but anyway,
urlencoding is not appropriate there.
Comment 10 omniplex 2006-05-24 01:42:58 UTC
re #9: Please state the precise section of RFC 3986 (STD 66)
where "+" is mentioned as placeholder for spaces, I'm far
from knowing this monster (or its predecessors 2396 + 1738)
by heart. It's tricky stuff, especially the query part, e.g.
"=", "&", and ";" are only conventions, no standard.
Comment 11 Brion Vibber 2006-05-24 06:36:22 UTC
From what I can see, the "+" replacement is actually specified in 
the HTML standard for application/x-www-form-urlencoded encoding 
of submitted form data:

It's not directly related to either URLs or HTTP.
Comment 12 Rob Church 2006-05-24 08:58:42 UTC
If {{urlencode}} was changed so it switched spaces over to %20, would that be
Comment 13 omniplex 2006-05-26 05:50:20 UTC
re #12: Most probably. I'm not sure why it strips trailing spaces,
but preserves (= encodes) leading spaces.  
Comment 14 Eric L. Frederich 2006-09-15 17:34:13 UTC
I think I came across this same problem trying to use the following template.
The idea was so on a page for an rasterized image, the source could be provided
in a Visio / Power Point / Gimp / etc. file.
The problem is when the file name has a space in it, if I don't use urlencode,
it doesn't work at all on file names with a space.
If I use it with urlencode, it uses +'s instead of _'s and when I go to the
upload page the Destination file name has spaces in it.
Then when I upload the file I get a warning that the file name will be changed.
 It winds up working out, but it would be nice if there was a function that
actually put underscores instead of plus signs.


| [[Media:{{{1}}}]] || Download the {{{2}}} file
| [{{fullurl:Special:Upload|wpDestFile={{urlencode:{{{1}}}}}}} Upload] || Upload
a new version of this file
| [[:Image:{{{1}}}]] || {{{2}}} file page
Comment 15 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-10-29 22:06:02 UTC
Problem: if we call urlencode on the parameter, multiple parameters can't be
attached.  "action=edit&uselang=zh" would be escaped into gibberish.  This could
of course be solved using {{fullurl: foo|bar=x|baz=y}} instead of
|bar=x&baz=y}}, but that wouldn't be reverse-compatible.  Seeing as this isn't
really needed what with {{urlencode:}}, should we break reverse compatibility
for it?
Comment 16 Dan Li 2006-10-29 22:13:33 UTC
For one, Brion doesn't seem to like {{fullurl:foo|bar=x|baz=y}} (see Bug
Activity for Bug 7348).
Comment 17 Jesse (Pathoschild) 2007-06-01 01:17:37 UTC
{{fullurl:Apple juice|action=edit}} now outputs "http://...Apple_juice&action=edit"; I've marked this bug as resolved.
Comment 18 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-01 05:37:58 UTC
What?  This is about something different.  Possibly WONTFIX, but definitely not FIXED.
Comment 19 Borgx 2007-06-02 13:26:11 UTC
(In reply to comment #0)
Instead of 
 [http://server/wiki/Special:Log/block?page=User:Locke Cole link]
I use
 [http://server/wiki/Special:Log/block?page={{anchorencode:User:Locke Cole}} link]
which replace the space with underscore
Comment 20 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-03 02:01:55 UTC
Don't use anchorencode for that.  It will fail on unusual characters.  Use {{urlencode:}} for URLs, {{anchorencode:}} for anchors (stuff that goes after the # in a URL).

This is really not worth it by now.
Comment 21 Waldir 2008-01-13 01:18:26 UTC
What if fullurle only encoded spaces as "_" and possibly other special characters, but left &s, =s and #s alone? wouldn't that be backward compatible?

Note You need to log in before you can comment on or make changes to this bug.