Page MenuHomePhabricator

Relative links to Phriction pages misinterprets URL-encoded characters
Closed, ResolvedPublic


  1. From a Phriction page, create a New Document
  2. In the resulting form put a comma character in the URL
    Screen Shot 2017-03-02 at 9.51.31 PM.png (380×1 px, 36 KB)
  3. Create the page and note the URI field
    Screen Shot 2017-03-02 at 9.52.21 PM.png (318×1 px, 35 KB)
  4. The resulting page after saving will have the URL-encoded comma (%2C)
  5. Edit the page and put in the following content to compare results
[[ https://WEBSITE/w/lambda/jan_27%2C_2017/ | Fully-Qualified ]]
[[ lambda/jan_27%2C_2017/ | URL-Encoded Relative ]]
[[ /w/lambda/jan_27%2C_2017/ | URL-Encoded Root ]]
[[ lambda/jan_27,_2017/ | No-Encoding Relative ]]
[[ /w/lambda/jan_27,_2017/ | No-Encoding Root ]]
  1. The resulting page looks like:
    Screen Shot 2017-03-02 at 10.05.37 PM.png (506×734 px, 47 KB)
  2. The resulting links are
    1. The URL-Encoded Relative is linked as https://WEBSITE/w/lambda/jan_27_2c_2017/
    2. All the others are https://WEBSITE/w/lambda/jan_27,_2017/
    3. No-Encoding Relative is bold (feature? I've been linking this way for over a year and actually like the bold not realizing other style linking didn't bold)

I've been meaning to file this for a long time but it's been only a minor nuisance that I wasn't motivated until seeing T12343.


Event Timeline

cspeckmim renamed this task from Relative links to Phriction pages mis-encode URL-encoded characters to Relative links to Phriction pages misinterprets URL-encoded characters.Mar 3 2017, 3:15 AM

Just curious, but is the bold effect intentional in the "No Encoding Relative" scenario?

Oh! Yes. Sort of.

[[ /X/Y/Z/ ]] is a relative link, like [[ ]], where the protocol and domain are implied.

[[ X/Y/Z ]] (with no leading /) is a link to a Phriction document.

This is maybe a little more clear if you don't specify a title so the different rules fill one in. Consider:

The bold indicates "this is a recognized wiki page". A better rendering eventually might be something more like the grey tag around "T12344" or have a little icon or something and/or get a hovercard.

(Internally, the two cases are handled by completely separate remarkup rules: PhrictionRemarkupRule vs PhutilRemarkupDocumentLinkRule.)

A somewhat-related issue is T5378, where doesn't get recognized as special, even though we "know" what that link points at and could reasonably give it special treatment and a hovercard and such (and doing so would be nice, it's just a bit tricky). An extension of that might be to treat [[ /T123 ]] more like T123, and thus [[ /w/x/y/z/ ]] more like [[ x/y/z ]]. When T5378 moves forward I expect to give this more attention.

The non-bold ones also open in a new tab.


Locally, it looks like your full original test case is in good shape:

Screen Shot 2018-02-16 at 10.19.46 AM.png (255×255 px, 19 KB)