Wicket
  1. Wicket
  2. WICKET-3602

Wrong relative URLs in an error page during error dispatching when using non-empty context path or wicket filter prefix

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 1.5-RC3
    • Fix Version/s: None
    • Component/s: wicket
    • Labels:
      None
    • Environment:
      Tomcat 5

      Description

      since 1.5-RC3 the rendering of error pages does not work properly. All relative URLs inside a page are incorrect.
      Sample scenario:

      • create an error page
      • mount it in the Application class
      • define <error-page> in the web.xml pointing to the error page
      • start the application using some non-empty context path (or configure a filterPrefix - something like /blabla/* instead of /* in the web.xml)
      • navigate to a non existing page
        Expected:
        the error page must be shown with JavaScript and CSS resources loaded correctly and links containing correct relative urls.
        Result:
        the error page is shown, but none of the resources are loaded (404), links and buttons does not work

      This problem was already there in 1.4.x (WICKET-2712) and it was fixed. With the latest changes in ServletWebRequest class, the problem occurs again. According to the source code, the error page handling was extended in 1.5-RC3 to preserve a client URL (shouldPreserveClientUrl method in ServletWebRequest class). The intention of the change is ok, since before that, a redirect was made and the user did no see his/her wrong URL in the browser address bar. But the implementation seems to be inconsistent, since all URLs are resolved against the client URL from the request (ErrorAttributes#getRequestUri) and this url is wrong and non-existing and resource can be resolved against it.
      The method "getClientUrl" in ServletWebRequest returns the original error URL obtained from the forward request. And UrlRenderer uses it as its baseUrl, which is wrong, since this URL is not a Wicket Filter URL and UrlRenderer#renderRelativeUrl returns incorrect relative URLs for that.
      The patch would be either to make UrlRenderer#renderRelativeUrl work not only with Wicket Filter urls (which is quite complex I assume) or to correct ServletWebRequest#getClientUrl to return the URL of the error page (ServletWebRequest#getUrl(httpServletRequest, filterPrefix)) relativized to the original error URL from the forward request (ErrorAttributes#getRequestUri).
      There is an attachment with the quickstart application:
      WicketFilter is configured with the URL mapping /ui/*. Go to the home page and follow "Go to a non existing page" link. The error page is going to be shown. If everything works, the background of the body must be red and the link "Go to HomePage" must proceed again to the home page.
      My intention was to fix ServletWebRequest#getClientUrl. If it's ok, I will try to provide a patch.

      1. wicket-errorpage.zip
        9 kB
        Sergiy Barlabanov

        Issue Links

          Activity

          Hide
          Bertrand Guay-Paquet added a comment -

          The workarounds above don't work with Wicket 1.5.3 anymore. In fact, when I removed my code, the error pages started working again!

          I suspect there's something I don't understand about filter prefixes and context roots...

          Show
          Bertrand Guay-Paquet added a comment - The workarounds above don't work with Wicket 1.5.3 anymore. In fact, when I removed my code, the error pages started working again! I suspect there's something I don't understand about filter prefixes and context roots...
          Hide
          Bertrand Guay-Paquet added a comment -

          If you don't want to modify Wicket, there is another option for the workaround suggested above. Add the following to your WebApplication subclass :

          @Override
          protected WebRequest newWebRequest(HttpServletRequest servletRequest, String filterPath) {
          ServletWebRequest webRequest = new ServletWebRequest(servletRequest, filterPath) {
          @Override
          public Url getClientUrl() {
          Url clientUrl = super.getClientUrl();
          if (shouldPreserveClientUrl())

          { HttpServletRequest httpServletRequest = getContainerRequest(); final int start = httpServletRequest.getContextPath().length() + getFilterPrefix().length() + 1; String path = clientUrl.getPath(); clientUrl = Url.parse(path.substring(start), getCharset()); clientUrl.setPort(httpServletRequest.getServerPort()); clientUrl.setHost(httpServletRequest.getServerName()); clientUrl.setProtocol(httpServletRequest.getScheme()); return clientUrl; }

          else

          { return clientUrl; }

          }
          };
          return webRequest;
          }

          Show
          Bertrand Guay-Paquet added a comment - If you don't want to modify Wicket, there is another option for the workaround suggested above. Add the following to your WebApplication subclass : @Override protected WebRequest newWebRequest(HttpServletRequest servletRequest, String filterPath) { ServletWebRequest webRequest = new ServletWebRequest(servletRequest, filterPath) { @Override public Url getClientUrl() { Url clientUrl = super.getClientUrl(); if (shouldPreserveClientUrl()) { HttpServletRequest httpServletRequest = getContainerRequest(); final int start = httpServletRequest.getContextPath().length() + getFilterPrefix().length() + 1; String path = clientUrl.getPath(); clientUrl = Url.parse(path.substring(start), getCharset()); clientUrl.setPort(httpServletRequest.getServerPort()); clientUrl.setHost(httpServletRequest.getServerName()); clientUrl.setProtocol(httpServletRequest.getScheme()); return clientUrl; } else { return clientUrl; } } }; return webRequest; }
          Hide
          Bertrand Guay-Paquet added a comment -

          I had this problem so I tried a simple fix. Here is the 2 liner in org.apache.wicket.protocol.http.servlet.ServletWebRequest.getClientUrl():
          Replace
          if (errorAttributes != null && !Strings.isEmpty(errorAttributes.getRequestUri()))

          { return setParameters(Url.parse(errorAttributes.getRequestUri(), getCharset())); }

          with
          if (errorAttributes != null && !Strings.isEmpty(errorAttributes.getRequestUri()))

          { final int start = httpServletRequest.getContextPath().length() + filterPrefix.length() + 1; return setParameters(Url.parse(errorAttributes.getRequestUri().substring(start), getCharset())); }

          This code does the same thing as the getUrl() method does, which is stripping the servlet context part. Are there any cases where this would not work? If not, could this be a simple fix of this issue without requiring the big rework mentioned by Igor? (at least for 1.5)

          Note:
          While investigating the same problem, I found this issue. To make the quickstart run, I had to modify pom.xml by removing the following lines :
          <dependency>
          <groupId>log4j</groupId>
          <artifactId>log4j</artifactId>
          <version>1.2.15</version>
          </dependency>

          For some reason, this caused me a dependency problem with jmx...

          Show
          Bertrand Guay-Paquet added a comment - I had this problem so I tried a simple fix. Here is the 2 liner in org.apache.wicket.protocol.http.servlet.ServletWebRequest.getClientUrl(): Replace if (errorAttributes != null && !Strings.isEmpty(errorAttributes.getRequestUri())) { return setParameters(Url.parse(errorAttributes.getRequestUri(), getCharset())); } with if (errorAttributes != null && !Strings.isEmpty(errorAttributes.getRequestUri())) { final int start = httpServletRequest.getContextPath().length() + filterPrefix.length() + 1; return setParameters(Url.parse(errorAttributes.getRequestUri().substring(start), getCharset())); } This code does the same thing as the getUrl() method does, which is stripping the servlet context part. Are there any cases where this would not work? If not, could this be a simple fix of this issue without requiring the big rework mentioned by Igor? (at least for 1.5) Note: While investigating the same problem, I found this issue. To make the quickstart run, I had to modify pom.xml by removing the following lines : <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.15</version> </dependency> For some reason, this caused me a dependency problem with jmx...
          Hide
          Igor Vaynberg added a comment -

          thinking more about this, we dont need to normalize urls to /context/filter, just to /filter since contexts own their url space.

          Show
          Igor Vaynberg added a comment - thinking more about this, we dont need to normalize urls to /context/filter, just to /filter since contexts own their url space.
          Hide
          Igor Vaynberg added a comment -

          in 1.5.x we are only going to support error pages where the most common filter mapping of /* is used.

          the problem with this issue is that in 1.5 the url infrastructure is built to work with urls which are based off the filter path. meaning that if app lives in /context/filter the urls we deal with are all children of /context/filter url space. this makes sense because if a url is not a child of that url space wicket will not be handling it.

          however, error urls are an exception. they can live outside the /context/filter url space, but can still be configured to be handled by wicket. this causes a problem because there is no good way to handle these outsider urls in the infrastructure currently.

          we will have to refactor the url infrastructure to not use the assumption that the only urls we want to work with are children of the filter's url space. but, this is a big refactor that touches a lot of parts and we should hold off until a later version - such as 1.6 or later.

          Show
          Igor Vaynberg added a comment - in 1.5.x we are only going to support error pages where the most common filter mapping of /* is used. the problem with this issue is that in 1.5 the url infrastructure is built to work with urls which are based off the filter path. meaning that if app lives in /context/filter the urls we deal with are all children of /context/filter url space. this makes sense because if a url is not a child of that url space wicket will not be handling it. however, error urls are an exception. they can live outside the /context/filter url space, but can still be configured to be handled by wicket. this causes a problem because there is no good way to handle these outsider urls in the infrastructure currently. we will have to refactor the url infrastructure to not use the assumption that the only urls we want to work with are children of the filter's url space. but, this is a big refactor that touches a lot of parts and we should hold off until a later version - such as 1.6 or later.
          Hide
          Igor Vaynberg added a comment -

          i will look into this soonish.

          Show
          Igor Vaynberg added a comment - i will look into this soonish.
          Hide
          Sergiy Barlabanov added a comment -

          it is reproducable on trunk with the quickstart app attached to this jira task. As I said, it works, if the application is deployed under root context ("/") and the filter mapping in web.xml is empty ("/*"). As soon, as filter mapping or non-empty context comes in play, it does not work.

          Show
          Sergiy Barlabanov added a comment - it is reproducable on trunk with the quickstart app attached to this jira task. As I said, it works, if the application is deployed under root context ("/") and the filter mapping in web.xml is empty ("/*"). As soon, as filter mapping or non-empty context comes in play, it does not work.
          Hide
          Martin Grigorov added a comment -

          Yes, I also didn't find a way to fix this problem without reverting the improvement for WICKET-3551.
          But as I said before in WICKET-3551: I wasn't able to reproduce the described problem there. It was working for me.

          Show
          Martin Grigorov added a comment - Yes, I also didn't find a way to fix this problem without reverting the improvement for WICKET-3551 . But as I said before in WICKET-3551 : I wasn't able to reproduce the described problem there. It was working for me.
          Hide
          Sergiy Barlabanov added a comment -

          my problem is, that in order to make it work, ServletWebRequest#getClientUrl must return mapped url of the error page relative to the URI from the request. Only than UrlRenderer produces correct relative urls. But in this case, the value returned from getClientUrl does not match the semantic of the method described in Request#getClientUrl, which says: "Returns the url against which the client, usually the browser, will resolve relative urls in the rendered markup".
          So I am not sure, where I should fix the problem: is it ServletWebRequest#getClientUrl, that has to be fixed or is it UrlRenderer, which is not able to deal with the client url correctly.

          Show
          Sergiy Barlabanov added a comment - my problem is, that in order to make it work, ServletWebRequest#getClientUrl must return mapped url of the error page relative to the URI from the request. Only than UrlRenderer produces correct relative urls. But in this case, the value returned from getClientUrl does not match the semantic of the method described in Request#getClientUrl, which says: "Returns the url against which the client, usually the browser, will resolve relative urls in the rendered markup". So I am not sure, where I should fix the problem: is it ServletWebRequest#getClientUrl, that has to be fixed or is it UrlRenderer, which is not able to deal with the client url correctly.
          Hide
          Martin Grigorov added a comment -

          Patches are always welcome. Don't ask to provide them
          Please also test the requirement in WICKET-3551 with your patch.
          Thanks!

          Show
          Martin Grigorov added a comment - Patches are always welcome. Don't ask to provide them Please also test the requirement in WICKET-3551 with your patch. Thanks!

            People

            • Assignee:
              Igor Vaynberg
              Reporter:
              Sergiy Barlabanov
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Development