[jira] [Assigned] (WICKET-3602) Wrong relative URLs in an error page during error dispatching when using non-empty context path or wicket filter prefix

["Igor Vaynberg (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Igor Vaynberg reassigned WICKET-3602:
-------------------------------------

    Assignee: Igor Vaynberg

i will look into this soonish.

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