[jira] Issue Comment Edited: (WICKET-1449) './' appended to URL causes HTTP 404 in Internet Explorer (using root context)

["Vjacheslav Kanivetc (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WICKET-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659600#action_12659600 ] 

vjaka edited comment on WICKET-1449 at 12/29/08 10:40 AM:
------------------------------------------------------------------------

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.

      was (Author: vjaka):
    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

  
> './' appended to URL causes HTTP 404 in Internet Explorer (using root context)
> ------------------------------------------------------------------------------
>
>                 Key: WICKET-1449
>                 URL: https://issues.apache.org/jira/browse/WICKET-1449
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.3.2
>         Environment: Wicket 1.3.2 
> JBoss 4.0/Jetty 6.1.7 
> JDK 1.6.0_03
>            Reporter: Will Hoover
>            Assignee: Igor Vaynberg
>             Fix For: 1.3.5
>
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> 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).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.