Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 1.0
-
Fix Version/s: 1.1
-
Component/s: HTML Generation
-
Labels:None
Description
I have used displaytag to create a set of portlets that are hosted on a Tomcat server and accessed through an Epicentric portal. Some of these portlets contain tables that are generated through displaytags. The hrefs that are generated on these tables end up with the href parameters separated by "&". This works OK as long as the hrefs are accessed directly.
The problem is that, when the Epicentric portal (and most other portals) access the portlet, it transforms the direct href into a parameter to a portal-proxied href. For example, in this particular case, an href that appears as something like this:
http://torahmdfmnzj21:8080/Promotions/detailList.do/detailList.jsp?param1=A¶m2=B
gets transformed into this:
index.jsp?epiproxyrealurl=http%3a%2f%2ftorahmdfmnzj21%3a8080%2fPromotions%2fdetailList%2edo%2fdetailList%2ejsp%3fparam1%3dA%26param2%3dB
The problem comes when displaytag generates sort links for table headings. The bare href looks like this (note that I'm making these up, they're not actual hrefs, just something similar):
http://torahmdfmnzj21:8080/Promotions/detailList.do/detailList.jsp?d-2371270-o=1&d-2371270-s=2
The devil comes with the "&" used as the parameter separator, which results from using TagConstants.AMPERSAND in the Href.toString() method. The portal transforms this into:
index.jsp?epiproxyrealurl=http%3a%2f%2ftorahmdfmnzj21%3a8080%2fPromotions%2fdetailList%2edo%2fdetailList%2ejsp%3fd-2371270-o%3d1%26amp;d-2371270-s%3d2
This time when it posts back, that %26amp; doesn't get transformed into & and then plain & by the browser. Instead the ampersand performs its function separating parameters, while the "amp;" becomes part of the following parameter, meaning that you get a request parameter like this:
amp;d-2371270-s
Each time you click the link, it'll post back and the "amp;" accretes, resulting things like:
amp;amp;amp;amp;d-2371270-s
The fact that "&" works as a parameter separator in the browser is dependent on the fact that the browser will transform that properly. In fact, it is technically correct only to use the '&' directly in the URL. The TagConstants.AMPERSAND should either be changed to be "&" or '&' should be used directly in the Href.toString() method, just as '?' and '=' are.
The problem is that, when the Epicentric portal (and most other portals) access the portlet, it transforms the direct href into a parameter to a portal-proxied href. For example, in this particular case, an href that appears as something like this:
http://torahmdfmnzj21:8080/Promotions/detailList.do/detailList.jsp?param1=A¶m2=B
gets transformed into this:
index.jsp?epiproxyrealurl=http%3a%2f%2ftorahmdfmnzj21%3a8080%2fPromotions%2fdetailList%2edo%2fdetailList%2ejsp%3fparam1%3dA%26param2%3dB
The problem comes when displaytag generates sort links for table headings. The bare href looks like this (note that I'm making these up, they're not actual hrefs, just something similar):
http://torahmdfmnzj21:8080/Promotions/detailList.do/detailList.jsp?d-2371270-o=1&d-2371270-s=2
The devil comes with the "&" used as the parameter separator, which results from using TagConstants.AMPERSAND in the Href.toString() method. The portal transforms this into:
index.jsp?epiproxyrealurl=http%3a%2f%2ftorahmdfmnzj21%3a8080%2fPromotions%2fdetailList%2edo%2fdetailList%2ejsp%3fd-2371270-o%3d1%26amp;d-2371270-s%3d2
This time when it posts back, that %26amp; doesn't get transformed into & and then plain & by the browser. Instead the ampersand performs its function separating parameters, while the "amp;" becomes part of the following parameter, meaning that you get a request parameter like this:
amp;d-2371270-s
Each time you click the link, it'll post back and the "amp;" accretes, resulting things like:
amp;amp;amp;amp;d-2371270-s
The fact that "&" works as a parameter separator in the browser is dependent on the fact that the browser will transform that properly. In fact, it is technically correct only to use the '&' directly in the URL. The TagConstants.AMPERSAND should either be changed to be "&" or '&' should be used directly in the Href.toString() method, just as '?' and '=' are.
Just FYI, the Href.toString() method is the only place in the code where the TagConstants.AMPERSAND constant is referenced.