how & when extra encoding of % into %25 to turn URL blanks into %2520 in RRC links ?
It seems, since we upgraded to RRC 5.0.2 (Window/Tomcat), some of the new links are broken, due to a second encoding of % into %25 which turned encoded blanks of %20 into %2520. We have yet to isolate this to any browser.
Wonder where this extra encoding (or an existing one with %20 no longer an exception ?) came from.
Accepted answer
Hello Long,
It appears you're running into a defect similar to this one. But for a different scenario. The issue reported here are that links in a document are double encoded while they are converted. In your case, you're entering an already encoded URL when creating a hyperlink. I'm not sure, but it looks like it could be a bug.
Defect 94914: Spaces in links are double-encoded when opening from a converted document
It appears you're running into a defect similar to this one. But for a different scenario. The issue reported here are that links in a document are double encoded while they are converted. In your case, you're entering an already encoded URL when creating a hyperlink. I'm not sure, but it looks like it could be a bug.
Defect 94914: Spaces in links are double-encoded when opening from a converted document
Comments
Thx Erica,
Wonder why we have not seen this before (found in RRC 4.0.1) our current RRC 5.0.2, when we were at 4.0.3 and 4.0.6 ?
Caught this right after our first upgrade, to the TST env.
Hello Long,
As mentioned, the scenario described in the defect is related to double encoding in a URL, but is different. I would suggest opening a PMR to confirm if there is an existing defect for the behavior you described using the "add link" button. If not, support will help confirm if it is a defect and get one filed. I have not found an existing defect record with the same problem described.
Thanks.
I see the following defect record has been filed for this issue.
Defect 97845: % is double-encoded when entered in a link to a web page
3 other answers
The culprit is actually the RRC. Will check with IBM to see it is a bug in 5.0.2 or has always been, or intentional. Essentially it looks like RRC is expecting a non-encoded URL, with blanks stayed as literal blanks.
Here is what I found with my experiments
- When there are blanks, they are encoded into %20 in the URL, in the browser address slot. Nothing exciting, we all know that.
- When pasted into an RRC link, it looked same with the %20 intact.
- When you edit that same link in RRC, it showed up in the editor exactly same as when it was pasted, %20 intact.
- Don’t know if RRC stores the link with the extra encoding or not, but whenever the link is used or is copied, the effective URL got encoded a second time, all %20 become %2520. The way to test this is to paste and create the link then copy the link to compare with the original pasted string.
- %20 is not the only victim: so are %2F and %7, I guess all %-escaped chars.
I think it's up to the browser to do the encoding. I can't see this problem in my own CLM 5.0.2 environment with Chrome 42.0.2311.90 and Firefox 31.6.0 ESR. I have a different annoying issue with a link pasted into the rich text though - the ending right bracket ")" will be excluded from the link. This is what I will get in the rich text - you can see the "%" does not get encoded but ")" is left out.
This is more like a comment to Erica's answer.
IBM support & engineering has confirmed that this is a different scenario but same defect as the one Erica mentioned.
However, start wondering if this was an intentional enhancement or fix, introduced to deal with internal links with blanks like the fix introduced to RTC Eclipse clients 4.0.3: Without double URLencoding, any blank in the URL would stay as blank and caused problems.
In the RRC, if this were a fix, then it would cause issue for external URL, copied from the browser, with blanks URLencoded to %20 by default: Is it possible to have the second encoding restricted to blanks only, hence % will be left intact, instead of encoded to %25