You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Chris Colman (JIRA)" <ji...@apache.org> on 2010/10/05 01:34:56 UTC
[jira] Issue Comment Edited: (WICKET-2912) IE 8 gets 404 error
after continueToOriginalDestination() when app is at root context
[ https://issues.apache.org/jira/browse/WICKET-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12917811#action_12917811 ]
Chris Colman edited comment on WICKET-2912 at 10/4/10 7:33 PM:
---------------------------------------------------------------
I still haven't managed to get a minimal app that demonstrates this bug but it's still happening every time with the main app. Here's the http logs. They are identical for FF and IE up to a point:
Both FF and IE show these similar entries:
127.0.0.1 - - [05/Oct/2010:09:17:37 +1100] "GET /?wicket:interface=:0:body:systemPanel:loginSubpanel:modalWindow:content:tabs:panel:signupBtn::IBehaviorListener:0:-1&random=0.882715671707312 HTTP/1.1" 200 541
127.0.0.1 - - [05/Oct/2010:09:17:37 +1100] "GET /?wicket:interface=:0:body:systemPanel:loginSubpanel:modalWindow::IBehaviorListener:1:-1&random=0.7279478199762577 HTTP/1.1" 200 130
127.0.0.1 - - [05/Oct/2010:09:17:37 +1100] "GET / HTTP/1.1" 200 28222
127.0.0.1 - - [05/Oct/2010:09:17:37 +1100] "GET /resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js HTTP/1.1" 200 2371
127.0.0.1 - - [05/Oct/2010:09:17:37 +1100] "GET /resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js HTTP/1.1" 200 19800
127.0.0.1 - - [05/Oct/2010:09:17:37 +1100] "GET /resources/org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.css HTTP/1.1" 200 1398
127.0.0.1 - - [05/Oct/2010:09:17:37 +1100] "GET /resources/org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.js HTTP/1.1" 200 11533
127.0.0.1 - - [05/Oct/2010:09:17:37 +1100] "GET /swfobject.js HTTP/1.1" 200 6880
127.0.0.1 - - [05/Oct/2010:09:17:37 +1100] "GET /images/logo.png HTTP/1.1" 200 1707
127.0.0.1 - - [05/Oct/2010:09:17:40 +1100] "GET /content/productCategory/o/76429/c/1406 HTTP/1.1" 200 30633
127.0.0.1 - - [05/Oct/2010:09:17:42 +1100] "GET /?wicket:interface=:2:body:productCategoryPanel:items:0:prices:2:priceLink::IBehaviorListener:0:5&random=0.04588601021718497 HTTP/1.1" 200 6753
127.0.0.1 - - [05/Oct/2010:09:17:50 +1100] "GET /?wicket:interface=:2:body:productCategoryPanel:cartWindow:content:checkoutBtn::IBehaviorListener:0:5&random=0.8917142698954278 HTTP/1.1" 200 541
127.0.0.1 - - [05/Oct/2010:09:17:50 +1100] "GET /?wicket:interface=:2:body:productCategoryPanel:cartWindow::IBehaviorListener:1:5&random=0.22787581848448035 HTTP/1.1" 200 99
127.0.0.1 - - [05/Oct/2010:09:17:50 +1100] "GET /content/checkout/o/76429/or/2286 HTTP/1.1" 302 -
127.0.0.1 - - [05/Oct/2010:09:17:50 +1100] "GET /?wicket:interface=:4:::: HTTP/1.1" 200 10693
127.0.0.1 - - [05/Oct/2010:09:17:57 +1100] "POST /?wicket:interface=:4:body:addressFormPanel:form::IFormSubmitListener:: HTTP/1.1" 302 -
This must be an implicit 302 redirect because I don't explicitly perform any 302 redirects (that I know of). Maybe this is the redirect that occurs when a trailing slash is left of a URL?
After this point IE throws a 400 error and no more HTTP activity is logged whereas FF continues with the follow HTTP requests and displays the page perfectly:
127.0.0.1 - - [05/Oct/2010:09:17:57 +1100] "GET /content/checkout/o/76429/or/2286 HTTP/1.1" 200 28451
127.0.0.1 - - [05/Oct/2010:09:17:57 +1100] "GET /images/visa37.png HTTP/1.1" 304 -
127.0.0.1 - - [05/Oct/2010:09:17:57 +1100] "GET /images/mastercard37.png HTTP/1.1" 304 -
127.0.0.1 - - [05/Oct/2010:09:17:57 +1100] "GET /images/amex37.png HTTP/1.1" 304 -
127.0.0.1 - - [05/Oct/2010:09:17:57 +1100] "GET /images/discover37.png HTTP/1.1" 304 -
There is one thing that I noticed in my test app that exhibited different behaviour between IE and FF:
When I use a servlet instead of a filter to 'catch' requests that have no path via the welcome page mechanism (eg., www.abc.com instead of www.abc.com/content/home etc.,) then I do see a difference. IE attempts to load /favicon.ico and this causes a 404 crash because it's not there. When I use the filter on /* instead - IE works fine.
<!-- redirects requests without any path component (ie '/') to the appropriate URL -->
<servlet>
<servlet-name>redirector</servlet-name>
<servlet-class>com.mycompany.UrlRedirector</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>redirector</servlet-name>
<url-pattern>/redirectPureDomainName.jsp</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>redirectPureDomainName.jsp</welcome-file>
</welcome-file-list>
I might switch the app over to using a filter intead of a servlet for my 'redirector' function and see if that avoids the problem altogether.
Using this UrlRedirector to take advantage of the 'welcome page' feature to test 'domain name only' requests is probably not a good idea. It's probably best to convert it to a filter and do the appropriate "am I just a domain name with no suffix text" in the filter code.
Is there a best practice 'test' to perform on a Request to make sure we get no false positives on Wicket AJAX requests?
was (Author: chrisc):
I still haven't managed to get a minimal app that demonstrates this bug but it's still happening every time with the main app. Here's the http logs. They are identical for FF and IE up to a point:
Both FF and IE show these similar entries:
127.0.0.1 - - [05/Oct/2010:09:17:37 +1100] "GET /?wicket:interface=:0:body:systemPanel:loginSubpanel:modalWindow:content:tabs:panel:signupBtn::IBehaviorListener:0:-1&random=0.882715671707312 HTTP/1.1" 200 541
127.0.0.1 - - [05/Oct/2010:09:17:37 +1100] "GET /?wicket:interface=:0:body:systemPanel:loginSubpanel:modalWindow::IBehaviorListener:1:-1&random=0.7279478199762577 HTTP/1.1" 200 130
127.0.0.1 - - [05/Oct/2010:09:17:37 +1100] "GET / HTTP/1.1" 200 28222
127.0.0.1 - - [05/Oct/2010:09:17:37 +1100] "GET /resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js HTTP/1.1" 200 2371
127.0.0.1 - - [05/Oct/2010:09:17:37 +1100] "GET /resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js HTTP/1.1" 200 19800
127.0.0.1 - - [05/Oct/2010:09:17:37 +1100] "GET /resources/org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.css HTTP/1.1" 200 1398
127.0.0.1 - - [05/Oct/2010:09:17:37 +1100] "GET /resources/org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.js HTTP/1.1" 200 11533
127.0.0.1 - - [05/Oct/2010:09:17:37 +1100] "GET /swfobject.js HTTP/1.1" 200 6880
127.0.0.1 - - [05/Oct/2010:09:17:37 +1100] "GET /images/logo.png HTTP/1.1" 200 1707
127.0.0.1 - - [05/Oct/2010:09:17:40 +1100] "GET /content/productCategory/o/76429/c/1406 HTTP/1.1" 200 30633
127.0.0.1 - - [05/Oct/2010:09:17:42 +1100] "GET /?wicket:interface=:2:body:productCategoryPanel:items:0:prices:2:priceLink::IBehaviorListener:0:5&random=0.04588601021718497 HTTP/1.1" 200 6753
127.0.0.1 - - [05/Oct/2010:09:17:50 +1100] "GET /?wicket:interface=:2:body:productCategoryPanel:cartWindow:content:checkoutBtn::IBehaviorListener:0:5&random=0.8917142698954278 HTTP/1.1" 200 541
127.0.0.1 - - [05/Oct/2010:09:17:50 +1100] "GET /?wicket:interface=:2:body:productCategoryPanel:cartWindow::IBehaviorListener:1:5&random=0.22787581848448035 HTTP/1.1" 200 99
127.0.0.1 - - [05/Oct/2010:09:17:50 +1100] "GET /content/checkout/o/76429/or/2286 HTTP/1.1" 302 -
127.0.0.1 - - [05/Oct/2010:09:17:50 +1100] "GET /?wicket:interface=:4:::: HTTP/1.1" 200 10693
127.0.0.1 - - [05/Oct/2010:09:17:57 +1100] "POST /?wicket:interface=:4:body:addressFormPanel:form::IFormSubmitListener:: HTTP/1.1" 302 -
This must be an implicit 302 redirect because I don't explicitly perform any 302 redirects (that I know of). Maybe this is the redirect that occurs when a trailing slash is left of a URL?
After this point IE throws a 400 error and no more HTTP activity is logged whereas FF continues with the follow HTTP requests and displays the page perfectly:
127.0.0.1 - - [05/Oct/2010:09:17:57 +1100] "GET /content/checkout/o/76429/or/2286 HTTP/1.1" 200 28451
127.0.0.1 - - [05/Oct/2010:09:17:57 +1100] "GET /images/visa37.png HTTP/1.1" 304 -
127.0.0.1 - - [05/Oct/2010:09:17:57 +1100] "GET /images/mastercard37.png HTTP/1.1" 304 -
127.0.0.1 - - [05/Oct/2010:09:17:57 +1100] "GET /images/amex37.png HTTP/1.1" 304 -
127.0.0.1 - - [05/Oct/2010:09:17:57 +1100] "GET /images/discover37.png HTTP/1.1" 304 -
There is one thing that I noticed in my test app that exhibited different behaviour between IE and FF:
When I use a servlet instead of a filter to 'catch' requests that have no path via the welcome page mechanism (eg., www.abc.com instead of www.abc.com/content/home etc.,) then I do see a difference. IE attempts to load /favicon.ico and this causes a 404 crash because it's not there. When I use the filter on /* instead - IE works fine.
<!-- redirects requests without any path component (ie '/') to the appropriate URL -->
<servlet>
<servlet-name>redirector</servlet-name>
<servlet-class>com.mycompany.UrlRedirector</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>redirector</servlet-name>
<url-pattern>/redirectPureDomainName.jsp</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>redirectPureDomainName.jsp</welcome-file>
</welcome-file-list>
I might switch the app over to using a filter intead of a servlet for my 'redirector' function and see if that avoids the problem altogether.
> IE 8 gets 404 error after continueToOriginalDestination() when app is at root context
> -------------------------------------------------------------------------------------
>
> Key: WICKET-2912
> URL: https://issues.apache.org/jira/browse/WICKET-2912
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.9
> Environment: Occurs on both Windows and Linux
> Running Tomcat 6
> JDK 1.6
> Reporter: Chris Colman
> Fix For: 1.4.13, 1.5-M3
>
> Attachments: myproject.rar
>
>
> After recommendation we recently switched wicket app from /content to / (root) context. App was working fine before but after switching to root context calls to continueToOriginalDestination give 404 errors in IE but continues to work perfectly in FireFox and Opera.
> Patch to fix the problem:
> I have provided a fix to PageMap's continueToOriginalDestination that fixes the problem on IE and continues to work fine on FireFox and Opera for all the tests I could throw at it.
> This patch breaks some unit tests - probably tests that the redirect occurs on the exact interceptContinuationURL that was originally provided, naturally after stripping off the leading '/' these would no longer work.
> This fix may cause problems when the web app is NOT in the root context but I'm not sure - they may be fine with this.
> public final boolean continueToOriginalDestination()
> {
> // Get request cycle
> final RequestCycle cycle = RequestCycle.get();
> // If there's a place to go to
> if (interceptContinuationURL != null)
> {
> >> ADDED if ( interceptContinuationURL.length() > 0 && interceptContinuationURL.charAt(0) == '/' )
> >> ADDED interceptContinuationURL = interceptContinuationURL.substring(1);
> cycle.setRequestTarget(new
> RedirectRequestTarget(interceptContinuationURL));
> // Reset interception URL
> interceptContinuationURL = null;
> // Force session to replicate page maps
> dirty();
> return true;
> }
> return false;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.