Wicket
  1. Wicket
  2. WICKET-847

setResponsePage redirects to wrong url

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3.0-beta2
    • Fix Version/s: 1.3.5, 1.4-M3
    • Component/s: wicket
    • Labels:
      None

      Description

      When I do setResponsePage(MyHomePage.class) IE tries to show me "my.site.com/./" url and gets 404 response.
      Firefox just shows "my.site.com" without any troubles. I'm using wicket 1.3-beta2 and WicketFilter mapped to /*.
      It's being reproduced under tomcat only, jetty works fine. My tomcat version is 5.5.17.
      Quickstart project which reproduces the bug is attached.

        Issue Links

          Activity

          Hide
          Alastair Maw added a comment -

          A workaround for this is probably to mount your homepage in your application init() - mountBookmarkablePage(MyHomePage.class, "/home");
          Will look into this, though.

          Show
          Alastair Maw added a comment - A workaround for this is probably to mount your homepage in your application init() - mountBookmarkablePage(MyHomePage.class, "/home"); Will look into this, though.
          Hide
          Andrew Klochkov added a comment -

          The evil code is in the WebRequestCodingStrategy class:

          // We need to special-case links to the home page if we're at the
          // same level.
          if (result.length() == 0)

          { result = "./"; }

          A workaround is to override newWebResponse in Application subclass to prevent such redirects

          <pre>
          protected WebResponse newWebResponse(HttpServletResponse servletResponse)
          {
          return new BufferedWebResponse(servletResponse) {

          public CharSequence encodeURL(CharSequence url)

          { return "./".equals(url) ? "" : super.encodeURL(url); }

          };
          }
          </pre>

          Show
          Andrew Klochkov added a comment - The evil code is in the WebRequestCodingStrategy class: // We need to special-case links to the home page if we're at the // same level. if (result.length() == 0) { result = "./"; } A workaround is to override newWebResponse in Application subclass to prevent such redirects <pre> protected WebResponse newWebResponse(HttpServletResponse servletResponse) { return new BufferedWebResponse(servletResponse) { public CharSequence encodeURL(CharSequence url) { return "./".equals(url) ? "" : super.encodeURL(url); } }; } </pre>
          Hide
          Andrew Klochkov added a comment -

          A better workaround which solves some issues is to return "." instead of empty string.

          Show
          Andrew Klochkov added a comment - A better workaround which solves some issues is to return "." instead of empty string.
          Hide
          Alastair Maw added a comment -

          Tomcat is evidently lacking in the relative to absolute URL conversion on the 302 redirect here. We should probably just do it ourselves and not rely on one of the slightly more esoteric bits of the servlet-api spec for it.

          Show
          Alastair Maw added a comment - Tomcat is evidently lacking in the relative to absolute URL conversion on the 302 redirect here. We should probably just do it ourselves and not rely on one of the slightly more esoteric bits of the servlet-api spec for it.
          Hide
          Erik van Oosten added a comment - - edited

          I got bitten by this as well (with 1.4-m3).

          The failing combination is: Tomcat and IE (6 or 7).

          Firefox correctly interprets the "./" as "" so its okay to use Firefox + Tomcat.
          Jetty converts "./" to "", so its okay to use any borwser on Jetty.

          My workaround was to patch these two Wicket core files (I can confirm it works when redirecting to the home page):

          BookmarkablePageRequestTarget:
          ----------8<-------------------------
          public void respond(RequestCycle requestCycle)
          {
          if (pageClassRef != null && pageClassRef.get() != null)
          {
          if (requestCycle.isRedirect())
          {
          IRequestCycleProcessor processor = requestCycle.getProcessor();
          String redirectUrl = processor.getRequestCodingStrategy()
          .encode(requestCycle, this)
          .toString();
          // START OF PATCH
          if (redirectUrl.startsWith("./"))

          { redirectUrl = redirectUrl.substring(2); }

          // END OF PATCH
          requestCycle.getResponse().redirect(redirectUrl);
          }
          else

          { // Let the page render itself getPage(requestCycle).renderPage(); }

          }
          }
          ----------8<-------------------------

          RedirectRequestTarget:
          ----------8<-------------------------
          public void respond(RequestCycle requestCycle)
          {
          Response response = requestCycle.getResponse();
          response.reset();
          if (redirectUrl.startsWith("/"))
          {
          RequestContext rc = RequestContext.get();
          if (rc.isPortletRequest() && ((PortletRequestContext)rc).isEmbedded())

          { response.redirect(redirectUrl); }

          else
          {
          String location = RequestCycle.get()
          .getRequest()
          .getRelativePathPrefixToContextRoot() +
          this.redirectUrl.substring(1);
          // START OF PATCH
          if (location.startsWith("./"))

          { location = location.substring(2); }

          // END OF PATCH
          response.redirect(location);
          }
          }
          else if (redirectUrl.startsWith("http://") || redirectUrl.startsWith("https://"))

          { response.redirect(redirectUrl); }

          else

          { response.redirect(RequestCycle.get() .getRequest() .getRelativePathPrefixToWicketHandler() + redirectUrl); }

          }
          ----------8<-------------------------

          Show
          Erik van Oosten added a comment - - edited I got bitten by this as well (with 1.4-m3). The failing combination is: Tomcat and IE (6 or 7). Firefox correctly interprets the "./" as "" so its okay to use Firefox + Tomcat. Jetty converts "./" to "", so its okay to use any borwser on Jetty. My workaround was to patch these two Wicket core files (I can confirm it works when redirecting to the home page): BookmarkablePageRequestTarget: ---------- 8< ------------------------- public void respond(RequestCycle requestCycle) { if (pageClassRef != null && pageClassRef.get() != null) { if (requestCycle.isRedirect()) { IRequestCycleProcessor processor = requestCycle.getProcessor(); String redirectUrl = processor.getRequestCodingStrategy() .encode(requestCycle, this) .toString(); // START OF PATCH if (redirectUrl.startsWith("./")) { redirectUrl = redirectUrl.substring(2); } // END OF PATCH requestCycle.getResponse().redirect(redirectUrl); } else { // Let the page render itself getPage(requestCycle).renderPage(); } } } ---------- 8< ------------------------- RedirectRequestTarget: ---------- 8< ------------------------- public void respond(RequestCycle requestCycle) { Response response = requestCycle.getResponse(); response.reset(); if (redirectUrl.startsWith("/")) { RequestContext rc = RequestContext.get(); if (rc.isPortletRequest() && ((PortletRequestContext)rc).isEmbedded()) { response.redirect(redirectUrl); } else { String location = RequestCycle.get() .getRequest() .getRelativePathPrefixToContextRoot() + this.redirectUrl.substring(1); // START OF PATCH if (location.startsWith("./")) { location = location.substring(2); } // END OF PATCH response.redirect(location); } } else if (redirectUrl.startsWith("http://") || redirectUrl.startsWith("https://")) { response.redirect(redirectUrl); } else { response.redirect(RequestCycle.get() .getRequest() .getRelativePathPrefixToWicketHandler() + redirectUrl); } } ---------- 8< -------------------------
          Hide
          Igor Vaynberg added a comment -

          started the quickstart, clicked the link, everything seems to work in ff and ie

          Show
          Igor Vaynberg added a comment - started the quickstart, clicked the link, everything seems to work in ff and ie
          Hide
          Igor Vaynberg added a comment -

          just noticed matijn did commit the code mentioned in the comments, albeit silently. that is why it worked when i tried it.

          Show
          Igor Vaynberg added a comment - just noticed matijn did commit the code mentioned in the comments, albeit silently. that is why it worked when i tried it.
          Hide
          Vjacheslav Kanivetc added a comment -

          This patch is NOT included in 1.3.5, so fix for version is incorrect. I think it should be reapplied to 1.3.6 version at least.

          Show
          Vjacheslav Kanivetc added a comment - This patch is NOT included in 1.3.5, so fix for version is incorrect. I think it should be reapplied to 1.3.6 version at least.

            People

            • Assignee:
              Martijn Dashorst
              Reporter:
              Andrew Klochkov
            • Votes:
              3 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development