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
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