DisplayTag
  1. DisplayTag
  2. DISPL-170

Use of the TagConstants.AMPERSAND tag causes proxied displaytag hrefs to fail

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Minor 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&param2=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.

        Activity

        Hide
        Rick Herrick added a comment -
        Just a note: On my local installation, I changed the implementation of Href.toString() to use '&' directly instead of referencing TagConstants.AMPERSAND. This resolves the issue quite well and easily.

        Just FYI, the Href.toString() method is the only place in the code where the TagConstants.AMPERSAND constant is referenced.
        Show
        Rick Herrick added a comment - Just a note: On my local installation, I changed the implementation of Href.toString() to use '&' directly instead of referencing TagConstants.AMPERSAND. This resolves the issue quite well and easily. Just FYI, the Href.toString() method is the only place in the code where the TagConstants.AMPERSAND constant is referenced.
        Hide
        fabrizio giustina added a comment -
        note that in order to generate valid html & MUST be escaped, so this sound like a bug in epicentric (btw, no problems at all in url encoded in ibm websphere portal).
        I will add a configuration option to swich this feature off in 1.1 so that you can easily overcome this bug.
        Show
        fabrizio giustina added a comment - note that in order to generate valid html & MUST be escaped, so this sound like a bug in epicentric (btw, no problems at all in url encoded in ibm websphere portal). I will add a configuration option to swich this feature off in 1.1 so that you can easily overcome this bug.
        Hide
        Rick Herrick added a comment -
        Interesting that WebSphere works properly with that. This is an older version of Epicentric (actually ALL versions of Epicentric are older versions, since they're owned by Vignette now), so it appears that it does "dumb" processing of the URL and converts all & chars to & even when that ampersand is already part of an existing entity declaration. It then doesn't "unprocess" that encoding properly.

        A config option or declaration attribute would solve the problem just fine. Thanks!
        Show
        Rick Herrick added a comment - Interesting that WebSphere works properly with that. This is an older version of Epicentric (actually ALL versions of Epicentric are older versions, since they're owned by Vignette now), so it appears that it does "dumb" processing of the URL and converts all & chars to & even when that ampersand is already part of an existing entity declaration. It then doesn't "unprocess" that encoding properly. A config option or declaration attribute would solve the problem just fine. Thanks!
        Hide
        Balaji Natesan added a comment -
        I am having the same issue, my portlet is running on wls7.0.4 and the portal is on epicenter. I am gonnna fix the issue by changing the toString() method on HREF, and have my version of the display-tag.jar.
        Because of this im not able to page or sort when the page is viewed thru the portal, but standalone it works great bcoz of the fact that the browser is converting & into & before posting it.

        It would be a good fix to have.

        thanks,
        Bala
        Show
        Balaji Natesan added a comment - I am having the same issue, my portlet is running on wls7.0.4 and the portal is on epicenter. I am gonnna fix the issue by changing the toString() method on HREF, and have my version of the display-tag.jar. Because of this im not able to page or sort when the page is viewed thru the portal, but standalone it works great bcoz of the fact that the browser is converting & into & before posting it. It would be a good fix to have. thanks, Bala
        Hide
        Rick Herrick added a comment -
        As an extra bit of info for this problem, we're at Epicentric 4.0 or 4.1 for production, but we've started using Vignette 7.1 in development. 7.1 still has the same problem.
        Show
        Rick Herrick added a comment - As an extra bit of info for this problem, we're at Epicentric 4.0 or 4.1 for production, but we've started using Vignette 7.1 in development. 7.1 still has the same problem.
        Hide
        Christopher K Koenigsberg added a comment -
        The Struts "bean:write" tag has a nice attribute "filter" which defaults to "true" but can be explicitly set to "false", disabling any url encoding of the string...

        perhaps a similar "filter=false" could be provided here too.
        Show
        Christopher K Koenigsberg added a comment - The Struts "bean:write" tag has a nice attribute "filter" which defaults to "true" but can be explicitly set to "false", disabling any url encoding of the string... perhaps a similar "filter=false" could be provided here too.
        Hide
        fabrizio giustina added a comment -

        Displaytag now offers a way to easily plugin a different RequestHelper (and a different Href implementation) so you will be able to generate urls without encoded ampersands without the need for patching the code. The default implementation will continue to use encoded ampersands, since unencoded ampersands are not valid in html. You can take a look at the displaytag-portlet module or an example of an alternative RequestHelper/Href implementation
        Show
        fabrizio giustina added a comment - Displaytag now offers a way to easily plugin a different RequestHelper (and a different Href implementation) so you will be able to generate urls without encoded ampersands without the need for patching the code. The default implementation will continue to use encoded ampersands, since unencoded ampersands are not valid in html. You can take a look at the displaytag-portlet module or an example of an alternative RequestHelper/Href implementation

          People

          • Reporter:
            Rick Herrick
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: