You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Igor Vaynberg (JIRA)" <ji...@apache.org> on 2011/05/01 08:55:03 UTC
[jira] [Updated] (WICKET-3602) Wrong relative URLs in an error page
during error dispatching when using non-empty context path or wicket filter
prefix
[ https://issues.apache.org/jira/browse/WICKET-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg updated WICKET-3602:
----------------------------------
Fix Version/s: 1.6.0
in 1.5.x we are only going to support error pages where the most common filter mapping of /* is used.
the problem with this issue is that in 1.5 the url infrastructure is built to work with urls which are based off the filter path. meaning that if app lives in /context/filter the urls we deal with are all children of /context/filter url space. this makes sense because if a url is not a child of that url space wicket will not be handling it.
however, error urls are an exception. they can live outside the /context/filter url space, but can still be configured to be handled by wicket. this causes a problem because there is no good way to handle these outsider urls in the infrastructure currently.
we will have to refactor the url infrastructure to not use the assumption that the only urls we want to work with are children of the filter's url space. but, this is a big refactor that touches a lot of parts and we should hold off until a later version - such as 1.6 or later.
> Wrong relative URLs in an error page during error dispatching when using non-empty context path or wicket filter prefix
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-3602
> URL: https://issues.apache.org/jira/browse/WICKET-3602
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
> Affects Versions: 1.5-RC3
> Environment: Tomcat 5
> Reporter: Sergiy Barlabanov
> Assignee: Igor Vaynberg
> Fix For: 1.6.0
>
> Attachments: wicket-errorpage.zip
>
>
> since 1.5-RC3 the rendering of error pages does not work properly. All relative URLs inside a page are incorrect.
> Sample scenario:
> - create an error page
> - mount it in the Application class
> - define <error-page> in the web.xml pointing to the error page
> - start the application using some non-empty context path (or configure a filterPrefix - something like /blabla/* instead of /* in the web.xml)
> - navigate to a non existing page
> Expected:
> the error page must be shown with JavaScript and CSS resources loaded correctly and links containing correct relative urls.
> Result:
> the error page is shown, but none of the resources are loaded (404), links and buttons does not work
> This problem was already there in 1.4.x (WICKET-2712) and it was fixed. With the latest changes in ServletWebRequest class, the problem occurs again. According to the source code, the error page handling was extended in 1.5-RC3 to preserve a client URL (shouldPreserveClientUrl method in ServletWebRequest class). The intention of the change is ok, since before that, a redirect was made and the user did no see his/her wrong URL in the browser address bar. But the implementation seems to be inconsistent, since all URLs are resolved against the client URL from the request (ErrorAttributes#getRequestUri) and this url is wrong and non-existing and resource can be resolved against it.
> The method "getClientUrl" in ServletWebRequest returns the original error URL obtained from the forward request. And UrlRenderer uses it as its baseUrl, which is wrong, since this URL is not a Wicket Filter URL and UrlRenderer#renderRelativeUrl returns incorrect relative URLs for that.
> The patch would be either to make UrlRenderer#renderRelativeUrl work not only with Wicket Filter urls (which is quite complex I assume) or to correct ServletWebRequest#getClientUrl to return the URL of the error page (ServletWebRequest#getUrl(httpServletRequest, filterPrefix)) relativized to the original error URL from the forward request (ErrorAttributes#getRequestUri).
> There is an attachment with the quickstart application:
> WicketFilter is configured with the URL mapping /ui/*. Go to the home page and follow "Go to a non existing page" link. The error page is going to be shown. If everything works, the background of the body must be red and the link "Go to HomePage" must proceed again to the home page.
> My intention was to fix ServletWebRequest#getClientUrl. If it's ok, I will try to provide a patch.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira