It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×11,927
×5,825
×3,952

question asked: Apr 24 '15, 6:08 p.m.
question was seen: 8,018 times
last updated: Jun 04 '15, 12:19 p.m.

Related questions

FAQ - How this Forum works

how & when extra encoding of % into %25 to turn URL blanks into %2520 in RRC links ?

0
long TRUONG (365●4●118●146) | asked Apr 24 '15, 6:08 p.m.
 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

0
permanent link
Erica Tran (1.4k●7) | answered Apr 30 '15, 2:41 p.m.
JAZZ DEVELOPER
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

long TRUONG selected this answer as the correct answer
Comments
long TRUONG commented Apr 30 '15, 11:10 p.m.

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.

Erica Tran commented May 05 '15, 12:45 p.m.
JAZZ DEVELOPER

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.

Erica Tran commented Jun 04 '15, 12:19 p.m.
JAZZ DEVELOPER

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

Most liked answers|Newest answers ↑|Oldest answers

0
permanent link
long TRUONG (365●4●118●146) | answered May 22 '15, 11:37 a.m.
 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
0
permanent link
Donald Nong (14.5k●4●14) | answered Apr 26 '15, 10:19 p.m.
edited Apr 26 '15, 10:20 p.m.
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.
0
permanent link
long TRUONG (365●4●118●146) | answered Apr 25 '15, 10:08 p.m.
 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.


Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.