Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 6.0.0-beta2
    • Fix Version/s: 6.1.0, 1.5.9
    • Component/s: None
    • Labels:
      None

      Description

      During page transition wicket used to encode an '../../tisch' which results in an exception:

      Caused by: java.lang.IllegalArgumentException
      at org.apache.catalina.connector.Response.normalize(Response.java:1799)

      The transition (within an ajax call) :

      http://localhost:8080/wicket/bookmarkable/de.test.pool.manage.ManagePool?11
      http://localhost:8080/tisch

      IMHO the double parent ".." is correct

      There exists already an bugzilla issue created but rejected as invalid https://issues.apache.org/bugzilla/show_bug.cgi?id=53469.

      If the wicket code works as expected there must be an error in the tomcat.
      Maybe the wicket development team has closer access to the tomcat developers

      1. wicket-4645.zip
        5 kB
        Pedro Santos
      2. UrlRendererTest.java
        13 kB
        Marek Šabo
      3. test.zip
        10 kB
        Thijs Vonk

        Issue Links

          Activity

          Hide
          Martin Grigorov added a comment -

          Actually, I was the one who requested this normalization in Tomcat.
          Let's see whether we can convince the Tomcat devs that the urls above are OK.

          Show
          Martin Grigorov added a comment - Actually, I was the one who requested this normalization in Tomcat. Let's see whether we can convince the Tomcat devs that the urls above are OK.
          Hide
          Thijs Vonk added a comment - - edited

          Hi Martin,
          I was the one who filed the issue at tomcat.
          I'll try to create a small test case. And attach it to this and the bugzilla ticket. and here

          Show
          Thijs Vonk added a comment - - edited Hi Martin, I was the one who filed the issue at tomcat. I'll try to create a small test case. And attach it to this and the bugzilla ticket. and here
          Hide
          Martin Grigorov added a comment -

          As Mark Thomas described in Tomcat's Bugzilla he added unit tests for this and they pass.
          Please create a demo app that demonstrates the problem and attach it to their Bugzilla.

          Additionally: the URLs you pasted in this ticket are generated by Wicket 1.4, not by Wicket 6.

          Show
          Martin Grigorov added a comment - As Mark Thomas described in Tomcat's Bugzilla he added unit tests for this and they pass. Please create a demo app that demonstrates the problem and attach it to their Bugzilla. Additionally: the URLs you pasted in this ticket are generated by Wicket 1.4, not by Wicket 6.
          Hide
          Thijs Vonk added a comment -

          This is with wicket 1.4.20 as we are still using that version
          install this on tomcat 7.0.28
          hit it with http://localhost:8080/test-1, click the link and everything works
          do the same with http://localhost:8080/test-1/testpage/param1/value1, then click the link and check you're tomcat log...

          Show
          Thijs Vonk added a comment - This is with wicket 1.4.20 as we are still using that version install this on tomcat 7.0.28 hit it with http://localhost:8080/test-1 , click the link and everything works do the same with http://localhost:8080/test-1/testpage/param1/value1 , then click the link and check you're tomcat log...
          Hide
          Jens Zastrow added a comment -

          Have'nt used the version 1.4.x for month....

          org.apache.wicket.protocol.http.WebApplication [wicket] Started Wicket version 6.0.0-beta2 in DEVELOPMENT mode

          Show
          Jens Zastrow added a comment - Have'nt used the version 1.4.x for month.... org.apache.wicket.protocol.http.WebApplication [wicket] Started Wicket version 6.0.0-beta2 in DEVELOPMENT mode
          Hide
          Martin Grigorov added a comment -

          @Jens:
          From the ticket in Tomcat:
          "The URL that is being encoded is:
          ../../resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js?w:lm=1340711670"

          1) 'resources' is a the special path for Wicket resources in 1.4.
          In 1.5+ it is wicket/resource/...

          2) In Wicket 6 there is no wicket-event.js
          There is wicket-event-jquery.js now.

          @Both: You see this is an issue with Tomcat, not Wicket one.
          As you see Mark Thomas is responsive. Just follow up with him in Tomcat's issue tracker.

          Show
          Martin Grigorov added a comment - @Jens: From the ticket in Tomcat: "The URL that is being encoded is: ../../resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js?w:lm=1340711670" 1) 'resources' is a the special path for Wicket resources in 1.4. In 1.5+ it is wicket/resource/... 2) In Wicket 6 there is no wicket-event.js There is wicket-event-jquery.js now. @Both: You see this is an issue with Tomcat, not Wicket one. As you see Mark Thomas is responsive. Just follow up with him in Tomcat's issue tracker.
          Hide
          Thijs Vonk added a comment - - edited

          Ok so Mark points back to Wicket.
          I know 1.4.x is probably eol as soon as Wicket 6 hits the floor (or maybe it even already is).
          But is there a chance you could have a look. Or point me to the location where I should start digging?

          Show
          Thijs Vonk added a comment - - edited Ok so Mark points back to Wicket. I know 1.4.x is probably eol as soon as Wicket 6 hits the floor (or maybe it even already is). But is there a chance you could have a look. Or point me to the location where I should start digging?
          Hide
          Martin Grigorov added a comment -

          1.4.x branch is closed. Only security related fixes go in.
          Look in the URL coding strategy that is in use.

          Or just use Tomcat 7.0.27 until you upgrade to Wicket 6.

          Show
          Martin Grigorov added a comment - 1.4.x branch is closed. Only security related fixes go in. Look in the URL coding strategy that is in use. Or just use Tomcat 7.0.27 until you upgrade to Wicket 6.
          Hide
          Pedro Santos added a comment -

          quickstart simulating the issue with Wicket 6

          Show
          Pedro Santos added a comment - quickstart simulating the issue with Wicket 6
          Hide
          Martin Grigorov added a comment -

          REDIRECT_TO_BUFFER (the default strategy) is broken with the new checks in Tomcat if your application needs to encode jsessionid in the url instead of using a cookie.
          Use REDIRECT_TO_RENDER until there is a solution.

          MyApp#init()

          { ... getRequestCycleSettings().setRenderStrategy(IRequestCycleSettings.RenderStrategy.REDIRECT_TO_RENDER) }
          Show
          Martin Grigorov added a comment - REDIRECT_TO_BUFFER (the default strategy) is broken with the new checks in Tomcat if your application needs to encode jsessionid in the url instead of using a cookie. Use REDIRECT_TO_RENDER until there is a solution. MyApp#init() { ... getRequestCycleSettings().setRenderStrategy(IRequestCycleSettings.RenderStrategy.REDIRECT_TO_RENDER) }
          Hide
          Martin Grigorov added a comment -

          Fixed by making the url absolute before passing it to the web container.

          Show
          Martin Grigorov added a comment - Fixed by making the url absolute before passing it to the web container.
          Hide
          Martin Grigorov added a comment -

          Some more testing needs to be done here. UrlRenderer's baseUrl miss the contextPath and filterPath and this makes the resolved relative url invalid.

          Show
          Martin Grigorov added a comment - Some more testing needs to be done here. UrlRenderer's baseUrl miss the contextPath and filterPath and this makes the resolved relative url invalid.
          Hide
          Marek Šabo added a comment -

          Hello,

          I've attached test file with added unit test that fails due to a change to UrlRenderer in commit dda3eea1911dab0b58846221ae22bf795a03fd12

          Now resource URL get their context and filter paths stripped and replaced with "./" - this leads to URL's being out of sync with actual resource locations in portal (portlet container).

          Show
          Marek Šabo added a comment - Hello, I've attached test file with added unit test that fails due to a change to UrlRenderer in commit dda3eea1911dab0b58846221ae22bf795a03fd12 Now resource URL get their context and filter paths stripped and replaced with "./" - this leads to URL's being out of sync with actual resource locations in portal (portlet container).
          Hide
          Martin Grigorov added a comment -

          The produced result looks correct to me:

          base url: /my-portlets/my-app/configuration-page
          input: /my-portlets/my-app/wicket/resource/com.foo.bar.portlets.Anchor/res/Style-ver-1352751065000.css
          output: ./wicket/resource/com.foo.bar.portlets.Anchor/res/Style-ver-1352751065000.css
          used method: renderer.renderRelativeUrl(input);

          You ask for relative Url and Wicket produces a correct (I think) relative url.

          Here is the code that would produce what you need:
          String encodedFullUrlString = "/my-portlets/my-app/wicket/resource/com.foo.bar.portlets.Anchor/res/Style-ver-1352751065000.css";
          Url baseUrl = Url.parse("/my-portlets/my-app/configuration-page");
          Url encodedFullUrl = Url.parse(encodedFullUrlString);
          UrlRenderer renderer = new UrlRenderer(new MockWebRequest(baseUrl));
          String mangledUrl = renderer.renderFullUrl(encodedFullUrl);
          System.err.println(Url.parse(mangledUrl).toString(Url.StringMode.LOCAL));

          Show
          Martin Grigorov added a comment - The produced result looks correct to me: base url: /my-portlets/my-app/configuration-page input: /my-portlets/my-app/wicket/resource/com.foo.bar.portlets.Anchor/res/Style-ver-1352751065000.css output: ./wicket/resource/com.foo.bar.portlets.Anchor/res/Style-ver-1352751065000.css used method: renderer.renderRelativeUrl(input); You ask for relative Url and Wicket produces a correct (I think) relative url. Here is the code that would produce what you need: String encodedFullUrlString = "/my-portlets/my-app/wicket/resource/com.foo.bar.portlets.Anchor/res/Style-ver-1352751065000.css"; Url baseUrl = Url.parse("/my-portlets/my-app/configuration-page"); Url encodedFullUrl = Url.parse(encodedFullUrlString); UrlRenderer renderer = new UrlRenderer(new MockWebRequest(baseUrl)); String mangledUrl = renderer.renderFullUrl(encodedFullUrl); System.err.println(Url.parse(mangledUrl).toString(Url.StringMode.LOCAL));
          Hide
          Marek Šabo added a comment - - edited

          Hello,

          I agree that I get what I ask for with renderRelativeUrl, let me be more specific:

          I create JavascriptReferenceHeaderItem. In it's render method it calls private getUrl(), which calls RequectCycle.get().urlFor(). In that method I get correct mappedUrl. Then it's passed to private renderUrl() which calls UrlRenderer's renderUrl() and as the condition shouldRenderAsFull() return false - it is rendered as relative.

          shouldRenderAsFull() tests protocol, host and port. Neither of that is in my resource mappedUrl, it looks like "/my-portlets/my-app/wicket/resource/com.foo.bar.portlets.Anchor/res/Style-ver-1352751065000.css".

          For now I override render method and provide custom URL but I think we should try to reintroduce this back to Wicket core. Possibly find a spot in UrlRenderer where the removed condition ... return isAbsolute() ? mappedUrl.toString() :... (e.g. UrlRenderer#137) can be reinserted to allow absolute URLs without schema/host/port.

          Best regards

          Show
          Marek Šabo added a comment - - edited Hello, I agree that I get what I ask for with renderRelativeUrl, let me be more specific: I create JavascriptReferenceHeaderItem. In it's render method it calls private getUrl(), which calls RequectCycle.get().urlFor(). In that method I get correct mappedUrl. Then it's passed to private renderUrl() which calls UrlRenderer's renderUrl() and as the condition shouldRenderAsFull() return false - it is rendered as relative. shouldRenderAsFull() tests protocol, host and port. Neither of that is in my resource mappedUrl, it looks like "/my-portlets/my-app/wicket/resource/com.foo.bar.portlets.Anchor/res/Style-ver-1352751065000.css". For now I override render method and provide custom URL but I think we should try to reintroduce this back to Wicket core. Possibly find a spot in UrlRenderer where the removed condition ... return isAbsolute() ? mappedUrl.toString() :... (e.g. UrlRenderer#137) can be reinserted to allow absolute URLs without schema/host/port. Best regards

            People

            • Assignee:
              Martin Grigorov
              Reporter:
              Jens Zastrow
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development