Wicket
  1. Wicket
  2. WICKET-1449

'./' appended to URL causes HTTP 404 in Internet Explorer (using root context)

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: 1.3.2
    • Fix Version/s: 1.3.5
    • Component/s: wicket
    • Labels:
      None
    • Environment:
      Wicket 1.3.2
      JBoss 4.0/Jetty 6.1.7
      JDK 1.6.0_03

      Description

      SYNOPSIS:
      1) Web application is using the root context ("/")
      1) form.add(new Button("mybutton"));
      2) Button is clicked on any WebPage that is NOT MOUNTED

      ISSUE:
      WebRequestCodingStrategy.encode appends './' to the URL. The page is redirected to "http://www.mysite.com/./" It works fine in Firefox and Opera, but in IE an HTTP 404 ('.' page is not found) is rendered.

      Mounting the home page to something like '/home' solved the problem ('./' is not appended, but this causes a redirect every time a use hits the page).

        Activity

        Hide
        Martijn Dashorst added a comment -

        USE CRITICAL ONLY FOR ABSOLUTE BLOCKERS!

        Show
        Martijn Dashorst added a comment - USE CRITICAL ONLY FOR ABSOLUTE BLOCKERS!
        Hide
        Will Hoover added a comment -

        Default behavior that causes a malfunction in the whole application seems like a good candidate for an "absolute blocker" :o)

        Show
        Will Hoover added a comment - Default behavior that causes a malfunction in the whole application seems like a good candidate for an "absolute blocker" :o)
        Hide
        Will Hoover added a comment -

        Also... Isn't an "absolute blocker" supposed to use "Blocker" priority not "Critical"? ;o)

        Show
        Will Hoover added a comment - Also... Isn't an "absolute blocker" supposed to use "Blocker" priority not "Critical"? ;o)
        Hide
        Martijn Dashorst added a comment -

        when you are the only one to notice this as a bug, then it is not critical. Critical means nobody can work with a product or a security issue. Anything else has less priority.

        Show
        Martijn Dashorst added a comment - when you are the only one to notice this as a bug, then it is not critical. Critical means nobody can work with a product or a security issue. Anything else has less priority.
        Hide
        Will Hoover added a comment -

        Well, judging by the number of people that have posted the question on the forum (I counted 3 including myself) I would hardly say that it is JUST me. Besides, we all know that not everyone that experiences the problem will report the issue ;o)

        Any application that has an out-of the-box functionality that completely breaks the application in a commonly used browser seems like a critical issue to me, but from this point on I will only use priority of Major and below... Sorry for placing this issue in Critical priority status :o)

        Show
        Will Hoover added a comment - Well, judging by the number of people that have posted the question on the forum (I counted 3 including myself) I would hardly say that it is JUST me. Besides, we all know that not everyone that experiences the problem will report the issue ;o) Any application that has an out-of the-box functionality that completely breaks the application in a commonly used browser seems like a critical issue to me, but from this point on I will only use priority of Major and below... Sorry for placing this issue in Critical priority status :o)
        Hide
        Erik van Oosten added a comment -

        Duplicate of WICKET-847.

        I would rate this issue as a blocker as well.

        Show
        Erik van Oosten added a comment - Duplicate of WICKET-847 . I would rate this issue as a blocker as well.
        Hide
        Igor Vaynberg added a comment -

        tried with latest wicket-1.3.x and could not reproduce it, must already be fixed

        Show
        Igor Vaynberg added a comment - tried with latest wicket-1.3.x and could not reproduce it, must already be fixed
        Hide
        Vjacheslav Kanivetc added a comment - - edited

        Actually this problem is with 1.3.5 version as well,
        happens in IE only, does not matter if it is AjaxLink or Link, at least with REDIRECT_TO_BUFFER.
        It is difficult to reproduce on a simple quick start since it happens not with all links, in a large application (online browser web strategy game on wicket), we have 2 such links only.

        NOTE: This does not happen when the application content is delivered via AJP connector (like lighttpd), this happens only when tomcat is serving web contents

        The code is very simple:
        AjaxLink cityLink = new AjaxLink("cityLink") {
        @Override
        public void onClick(AjaxRequestTarget target)

        { GameSession session = GameSessionProvider.get(); session.setLastMyCity(ref); setResponsePage(CityPage.class); }

        };
        absolutely same with Link causes error "The requested resource (/./) is not available."

        The thing looking funny is the fact that as far as seen by requests, other links that works also does such redirect via /./, so this is some kind of floating bug

        The issue reoccured since we dropped running lighttpd + AJP connector to the NIO connector, with which the tomcat is being able to serve a lot of requests just same way lighttpd/nginx does without need of some proxying. Reproxyng this once again just in order to fix this framework bug will loose any bonuses that are got when moving to NIO from AJP.

        Show
        Vjacheslav Kanivetc added a comment - - edited Actually this problem is with 1.3.5 version as well, happens in IE only, does not matter if it is AjaxLink or Link, at least with REDIRECT_TO_BUFFER. It is difficult to reproduce on a simple quick start since it happens not with all links, in a large application (online browser web strategy game on wicket), we have 2 such links only. NOTE: This does not happen when the application content is delivered via AJP connector (like lighttpd), this happens only when tomcat is serving web contents The code is very simple: AjaxLink cityLink = new AjaxLink("cityLink") { @Override public void onClick(AjaxRequestTarget target) { GameSession session = GameSessionProvider.get(); session.setLastMyCity(ref); setResponsePage(CityPage.class); } }; absolutely same with Link causes error "The requested resource (/./) is not available." The thing looking funny is the fact that as far as seen by requests, other links that works also does such redirect via /./, so this is some kind of floating bug The issue reoccured since we dropped running lighttpd + AJP connector to the NIO connector, with which the tomcat is being able to serve a lot of requests just same way lighttpd/nginx does without need of some proxying. Reproxyng this once again just in order to fix this framework bug will loose any bonuses that are got when moving to NIO from AJP.
        Hide
        Igor Vaynberg added a comment -

        sounds like a tomcat bug if it worked fine with lighttpd, or at least lighttpd is smarter then tomcat at url handling...

        Show
        Igor Vaynberg added a comment - sounds like a tomcat bug if it worked fine with lighttpd, or at least lighttpd is smarter then tomcat at url handling...
        Hide
        Vjacheslav Kanivetc added a comment -

        See issue https://issues.apache.org/jira/browse/WICKET-1998 which is a continue of duplicate of this issue, the patch that worked for 1.4.x series was mistakenly not included to 1.3.x source tree, so needs to be fixed once again.

        Show
        Vjacheslav Kanivetc added a comment - See issue https://issues.apache.org/jira/browse/WICKET-1998 which is a continue of duplicate of this issue, the patch that worked for 1.4.x series was mistakenly not included to 1.3.x source tree, so needs to be fixed once again.

          People

          • Assignee:
            Igor Vaynberg
            Reporter:
            Will Hoover
          • Votes:
            3 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 72h
              72h
              Remaining:
              Remaining Estimate - 72h
              72h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development