Wicket
  1. Wicket
  2. WICKET-4168

Error page resource relative urls are wrong

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.5.2
    • Fix Version/s: 1.5.3
    • Component/s: wicket
    • Labels:
      None

      Description

      The wicket page exposed as 404 error page has wrong links to resources. The sample project is attached.

      Run the project with "mvn jetty:run" and go to url "http://localhost:8080/bug/404" - it's mapped wicket page, works perfect. But if you type any wrong url such as "http://localhost:8080/bug/aaaaaa" the page doesn't have styles and images.

      1. myproject.zip
        36 kB
        Anatoly Kupriyanov
      2. fix-WICKET-4168.patch
        1 kB
        Anatoly Kupriyanov

        Issue Links

          Activity

          Hide
          Pedro Santos added a comment -

          Why are you asking?
          OK, I will double check the setParameters usage.

          Show
          Pedro Santos added a comment - Why are you asking? OK, I will double check the setParameters usage.
          Hide
          Anatoly Kupriyanov added a comment -

          Also, the fix r1190596 invokes setParameters twice for error urls - from getContextRelativeUrl and after it.

          Show
          Anatoly Kupriyanov added a comment - Also, the fix r1190596 invokes setParameters twice for error urls - from getContextRelativeUrl and after it.
          Hide
          Anatoly Kupriyanov added a comment -

          Sorry. Are you sure it's fixed in 1.5.2??

          Show
          Anatoly Kupriyanov added a comment - Sorry. Are you sure it's fixed in 1.5.2??
          Hide
          Pedro Santos added a comment -

          Oh, also the the context path can't be empty. I'm using here
          class Start

          { ... bb.setContextPath("/bug"); ... }
          Show
          Pedro Santos added a comment - Oh, also the the context path can't be empty. I'm using here class Start { ... bb.setContextPath("/bug"); ... }
          Hide
          Pedro Santos added a comment -

          Hi, in order to simulate the bug here using Firefox I have to clean the browser cache each time I go to the problematic URL.

          Show
          Pedro Santos added a comment - Hi, in order to simulate the bug here using Firefox I have to clean the browser cache each time I go to the problematic URL.
          Hide
          Anatoly Kupriyanov added a comment -

          I do exactly the same! And it fails for me.
          Could you show content of the page? It should contain [<img src="logo.png" width..../>], but I have [<img src="../../logo.png" width.../>]. Also could you try "http://localhost:8080/4168/gf/s/h/h/f/fdhdhdh" please?

          Show
          Anatoly Kupriyanov added a comment - I do exactly the same! And it fails for me. Could you show content of the page? It should contain [<img src="logo.png" width..../>] , but I have [<img src="../../logo.png" width.../>] . Also could you try "http://localhost:8080/4168/gf/s/h/h/f/fdhdhdh" please?
          Hide
          Anatoly Kupriyanov added a comment -

          Fix added

          Show
          Anatoly Kupriyanov added a comment - Fix added
          Hide
          Martin Grigorov added a comment -

          I did:

          Show
          Martin Grigorov added a comment - I did: mvn package cp target/*.war $TC7/webapps/4168.war start TC7 open http://localhost:8080/4168 (home page) open http://localhost:8080/4168/gfshhffdhdhdh (the error page) open http://localhost:8080/4168/404 (the error page)
          Hide
          Anatoly Kupriyanov added a comment -

          Are you sure? Just tried it with JBossAS7 and Tomcat 7.0.22. Fails everywhere. I suspect you have deployed it on ROOT once, and "../../" works.

          As I see, the problem is in the getClientUrl method. If it's normal page it uses the private method "getUrl", and it does remove context and filter paths, but for an error page it doesn't. Hence all resource relative urls have extra 2 levels up "../../".

          Show
          Anatoly Kupriyanov added a comment - Are you sure? Just tried it with JBossAS7 and Tomcat 7.0.22. Fails everywhere. I suspect you have deployed it on ROOT once, and "../../" works. As I see, the problem is in the getClientUrl method. If it's normal page it uses the private method "getUrl", and it does remove context and filter paths, but for an error page it doesn't. Hence all resource relative urls have extra 2 levels up "../../".
          Hide
          Martin Grigorov added a comment -

          The application works fine when deployed at Tomcat 7.0.21 at context path /4168.
          Both /4168/404 and /4168/fasdshshds show the error page.
          I would blame maven-jetty-plugin or the config in this project's pom.xml

          Show
          Martin Grigorov added a comment - The application works fine when deployed at Tomcat 7.0.21 at context path /4168. Both /4168/404 and /4168/fasdshshds show the error page. I would blame maven-jetty-plugin or the config in this project's pom.xml
          Hide
          Martin Grigorov added a comment -

          I can add that the attached quickstart works fine when started with Start.java.
          It seems Jetty acts differently when started with 'mvn jetty:run' and embedded.
          Going to test with Tomcat7.

          Show
          Martin Grigorov added a comment - I can add that the attached quickstart works fine when started with Start.java. It seems Jetty acts differently when started with 'mvn jetty:run' and embedded. Going to test with Tomcat7.
          Hide
          Anatoly Kupriyanov added a comment -

          I think it should use error URI, because actual page could be on different level, not in root as /404. A test case for the fix should include urls like ""http://localhost:8080/bug/aaaaaa/bbbb/cccc". Also to check if it works after moving the "/404" mapping to somewhere else, e.g. "/error/http/404".

          Show
          Anatoly Kupriyanov added a comment - I think it should use error URI, because actual page could be on different level, not in root as /404. A test case for the fix should include urls like ""http://localhost:8080/bug/aaaaaa/bbbb/cccc". Also to check if it works after moving the "/404" mapping to somewhere else, e.g. "/error/http/404".
          Hide
          Pedro Santos added a comment -

          I don't know why ServletWebRequest#getClientUrl is testing error attributes in request and using the error URI, it is the address of the resource causing problems, but getClientUrl is designed to to return only the base URL without context or filter mapping.

          Simply remove the test for error attributes an its logic fix this BUG and have no impact at WICKET-3599, WICKET-3551 but breaks some test expectations.

          Show
          Pedro Santos added a comment - I don't know why ServletWebRequest#getClientUrl is testing error attributes in request and using the error URI, it is the address of the resource causing problems, but getClientUrl is designed to to return only the base URL without context or filter mapping. Simply remove the test for error attributes an its logic fix this BUG and have no impact at WICKET-3599 , WICKET-3551 but breaks some test expectations.
          Hide
          Pedro Santos added a comment -

          The problem is that ServletWebRequest#getClientUrl method is returning a client URL that includes the context path. When responding it uses the errorAttributes.getRequestUri() URL to create the client one.

          Show
          Pedro Santos added a comment - The problem is that ServletWebRequest#getClientUrl method is returning a client URL that includes the context path. When responding it uses the errorAttributes.getRequestUri() URL to create the client one.
          Hide
          Anatoly Kupriyanov added a comment -

          Sample project based on quickstart maven project.

          Show
          Anatoly Kupriyanov added a comment - Sample project based on quickstart maven project.

            People

            • Assignee:
              Pedro Santos
              Reporter:
              Anatoly Kupriyanov
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development