[
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.
