Guten Tag Martin Grigorov,
am Montag, 7. März 2016 um 10:06 schrieben Sie:
> Try with latest Tomcat release. There were some changes in this area
> recently.
I'm already using 7.0.67, the most current is only 7.0.68, but our
production server is an even older version maintained by apt, so I
would need a workaround in my app anyways.
> org.apache.wicket.protocol.http.servlet.ServletWebResponse#encodeRedirectURL
That's what I needed to find, thanks! This function behaves (nearly)
the same for my URLs, the only difference is the following line:
> Url originalUrl = Url.parse(url);
In my Tomcat I get a completely empty object, NOT null though, in the
quickstart with Jetty I get an object containing ".". But in the end
that doesn't seem to make any difference, both requests go through the
following:
> if (fullUrl.equals(encodedFullUrl))
> {
> // no encoding happened so just reuse the original url
> encodedUrl = url.toString();
> }
encodedUrl is "./" using Tomcat and Jetty as well, while "fullUrl"
contains an absolute URL in both cases:
> http://localhost:8080/org.example.frontend/
"./" is returned to ServletWebResponse.sendRedirect and runs into the
following:
> if (url.startsWith("./"))
> {
> /*
> * WICKET-4260 Tomcat does not canonalize urls, which leads to
> problems with IE
> * when url is relative and starts with a dot
> */
> url = url.substring(2);
> }
And that empties my URL and forwards it to the servlet container,
where Jetty instead of Tomcat seems to provide some magic to respond
with an absolute URL in the end. But my debugger says that in both
cases
> httpServletResponse.sendRedirect(url);
gets called with an empty string!
> But we'll let ServletWebResponse remove a leading "./" before passing the url
> to HttpServletRequest#sendRedirect().
> This does no harm and as you stated is essential as a workaround for the
> Tomcat/IE combination.
https://issues.apache.org/jira/browse/WICKET-4260?focusedCommentId=13247750&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13247750
It does harm in my case... ;-)
So, any ideas on how I can work around this and what should be the
correct behavior? Is having "./" already a problem or only to remove
it when there's nothing left anymore?
I don't see any callback or listener or such where I could influence
that behavior...
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
