You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Sergiy Barlabanov (JIRA)" <ji...@apache.org> on 2011/04/07 17:36:05 UTC
[jira] [Created] (WICKET-3602) Wrong relative URLs in an error page
during error dispatching when using non-empty context path or wicket filter
prefix
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
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 some non existing page
Expected:
the error page must be shown with JavaScript and CSS resources loaded correctly.
Result:
the error page is shown, but none of the resources are loaded (404).
This problem was already there in 1.4.x (WICKET-2712) and it was fixed. With the latest changed in ServletWebRequest class, the problem occurs again. According to the source code, the error page handlig 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 it's wrong and non-existing.
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.
The patch would be either to make UrlRenderer#renderRelativeUrl work not only with Wicket Filter urls or to correct ServletWebRequest#getClientUrl to return the URL of the error page (ServletWebRequest#getUrl(httpServletRequest, filterPrefix)) relativize 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
[jira] [Updated] (WICKET-3602) Wrong relative URLs in an error page
during error dispatching when using non-empty context path or wicket filter
prefix
Posted by "Martin Grigorov (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Grigorov updated WICKET-3602:
------------------------------------
Fix Version/s: (was: 6.0.0-beta1)
6.0.0-RC1
> 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
> Affects Versions: 1.5-RC3
> Environment: Tomcat 5
> Reporter: Sergiy Barlabanov
> Assignee: Igor Vaynberg
> Priority: Minor
> Fix For: 6.0.0-RC1
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-3602) Wrong relative URLs in an error page
during error dispatching when using non-empty context path or wicket filter
prefix
Posted by "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 updated WICKET-3602:
----------------------------------
Priority: Minor (was: Major)
> 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
> Priority: Minor
> 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
[jira] [Commented] (WICKET-3602) Wrong relative URLs in an error
page during error dispatching when using non-empty context path or wicket
filter prefix
Posted by "Sergiy Barlabanov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018806#comment-13018806 ]
Sergiy Barlabanov commented on WICKET-3602:
-------------------------------------------
my problem is, that in order to make it work, ServletWebRequest#getClientUrl must return mapped url of the error page relative to the URI from the request. Only than UrlRenderer produces correct relative urls. But in this case, the value returned from getClientUrl does not match the semantic of the method described in Request#getClientUrl, which says: "Returns the url against which the client, usually the browser, will resolve relative urls in the rendered markup".
So I am not sure, where I should fix the problem: is it ServletWebRequest#getClientUrl, that has to be fixed or is it UrlRenderer, which is not able to deal with the client url correctly.
> 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
> 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
[jira] [Updated] (WICKET-3602) Wrong relative URLs in an error page
during error dispatching when using non-empty context path or wicket filter
prefix
Posted by "Sergiy Barlabanov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sergiy Barlabanov updated WICKET-3602:
--------------------------------------
Attachment: wicket-errorpage.zip
> 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
> 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 some non existing page
> Expected:
> the error page must be shown with JavaScript and CSS resources loaded correctly.
> Result:
> the error page is shown, but none of the resources are loaded (404).
> This problem was already there in 1.4.x (WICKET-2712) and it was fixed. With the latest changed in ServletWebRequest class, the problem occurs again. According to the source code, the error page handlig 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 it's wrong and non-existing.
> 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.
> The patch would be either to make UrlRenderer#renderRelativeUrl work not only with Wicket Filter urls or to correct ServletWebRequest#getClientUrl to return the URL of the error page (ServletWebRequest#getUrl(httpServletRequest, filterPrefix)) relativize 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
[jira] [Updated] (WICKET-3602) Wrong relative URLs in an error page
during error dispatching when using non-empty context path or wicket filter
prefix
Posted by "Sergiy Barlabanov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sergiy Barlabanov updated WICKET-3602:
--------------------------------------
Description:
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.
was:
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 some non existing page
Expected:
the error page must be shown with JavaScript and CSS resources loaded correctly.
Result:
the error page is shown, but none of the resources are loaded (404).
This problem was already there in 1.4.x (WICKET-2712) and it was fixed. With the latest changed in ServletWebRequest class, the problem occurs again. According to the source code, the error page handlig 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 it's wrong and non-existing.
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.
The patch would be either to make UrlRenderer#renderRelativeUrl work not only with Wicket Filter urls or to correct ServletWebRequest#getClientUrl to return the URL of the error page (ServletWebRequest#getUrl(httpServletRequest, filterPrefix)) relativize 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.
> 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
> 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
[jira] [Commented] (WICKET-3602) Wrong relative URLs in an error
page during error dispatching when using non-empty context path or wicket
filter prefix
Posted by "Bertrand Guay-Paquet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099685#comment-13099685 ]
Bertrand Guay-Paquet commented on WICKET-3602:
----------------------------------------------
If you don't want to modify Wicket, there is another option for the workaround suggested above. Add the following to your WebApplication subclass :
@Override
protected WebRequest newWebRequest(HttpServletRequest servletRequest, String filterPath) {
ServletWebRequest webRequest = new ServletWebRequest(servletRequest, filterPath) {
@Override
public Url getClientUrl() {
Url clientUrl = super.getClientUrl();
if (shouldPreserveClientUrl()) {
HttpServletRequest httpServletRequest = getContainerRequest();
final int start =
httpServletRequest.getContextPath().length()
+ getFilterPrefix().length() + 1;
String path = clientUrl.getPath();
clientUrl = Url.parse(path.substring(start), getCharset());
clientUrl.setPort(httpServletRequest.getServerPort());
clientUrl.setHost(httpServletRequest.getServerName());
clientUrl.setProtocol(httpServletRequest.getScheme());
return clientUrl;
} else {
return clientUrl;
}
}
};
return webRequest;
}
> 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
> Affects Versions: 1.5-RC3
> Environment: Tomcat 5
> Reporter: Sergiy Barlabanov
> Assignee: Igor Vaynberg
> Priority: Minor
> 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
[jira] [Assigned] (WICKET-3602) Wrong relative URLs in an error
page during error dispatching when using non-empty context path or wicket
filter prefix
Posted by "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
[jira] [Commented] (WICKET-3602) Wrong relative URLs in an error
page during error dispatching when using non-empty context path or wicket
filter prefix
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13028409#comment-13028409 ]
Igor Vaynberg commented on WICKET-3602:
---------------------------------------
thinking more about this, we dont need to normalize urls to /context/filter, just to /filter since contexts own their url space.
> 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
> Priority: Minor
> 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
[jira] [Commented] (WICKET-3602) Wrong relative URLs in an error
page during error dispatching when using non-empty context path or wicket
filter prefix
Posted by "Bertrand Guay-Paquet (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165594#comment-13165594 ]
Bertrand Guay-Paquet commented on WICKET-3602:
----------------------------------------------
The workarounds above don't work with Wicket 1.5.3 anymore. In fact, when I removed my code, the error pages started working again!
I suspect there's something I don't understand about filter prefixes and context roots...
> 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
> Affects Versions: 1.5-RC3
> Environment: Tomcat 5
> Reporter: Sergiy Barlabanov
> Assignee: Igor Vaynberg
> Priority: Minor
> Fix For: 6.0.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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-3602) Wrong relative URLs in an error page
during error dispatching when using non-empty context path or wicket filter
prefix
Posted by "Bertrand Guay-Paquet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bertrand Guay-Paquet updated WICKET-3602:
-----------------------------------------
Comment: was deleted
(was: edit: the following only works for base urls at the root of the servlet.
Here is a workaround I am now using. Add the following to your sub-class of RequestCycle (works in 1.5-RC7):
@Override
protected UrlRenderer newUrlRenderer() {
UrlRenderer urlRenderer = super.newUrlRenderer();
Object request = getRequest().getContainerRequest();
if (request instanceof HttpServletRequest) {
HttpServletRequest httpRequest = (HttpServletRequest) request;
Integer code = (Integer) httpRequest.getAttribute("javax.servlet.error.status_code");
// If the request is for an error-page, use the request URL as the base URL.
// This avoids having wrong relative URLs for error page resources.
if (code != null) {
Url newBaseUrl = getRequest().getUrl();
urlRenderer.setBaseUrl(newBaseUrl);
}
}
return urlRenderer;
}
With this code, I get proper relative resource URLs. Are there any cases where this would not work? If not, could this form the basis of a simple fix of this issue without requiring the big rework mentioned by Igor? (at least for 1.5)
Note:
While investigating the same problem, I found this issue. To make the quickstart run, I had to modify pom.xml by removing the following lines :
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.15</version>
</dependency>
For some reason, this caused me a dependency problem with jmx...)
> 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
> Affects Versions: 1.5-RC3
> Environment: Tomcat 5
> Reporter: Sergiy Barlabanov
> Assignee: Igor Vaynberg
> Priority: Minor
> 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
[jira] [Updated] (WICKET-3602) Wrong relative URLs in an error page
during error dispatching when using non-empty context path or wicket filter
prefix
Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Grigorov updated WICKET-3602:
------------------------------------
Fix Version/s: (was: 6.0.0-beta2)
> 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
> Affects Versions: 1.5-RC3
> Environment: Tomcat 5
> Reporter: Sergiy Barlabanov
> Assignee: Igor Vaynberg
> Priority: Minor
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (WICKET-3602) Wrong relative URLs in
an error page during error dispatching when using non-empty context path or
wicket filter prefix
Posted by "Bertrand Guay-Paquet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13095487#comment-13095487 ]
Bertrand Guay-Paquet edited comment on WICKET-3602 at 9/1/11 6:25 PM:
----------------------------------------------------------------------
edit: the following only works for base urls at the root of the servlet.
Here is a workaround I am now using. Add the following to your sub-class of RequestCycle (works in 1.5-RC7):
@Override
protected UrlRenderer newUrlRenderer() {
UrlRenderer urlRenderer = super.newUrlRenderer();
Object request = getRequest().getContainerRequest();
if (request instanceof HttpServletRequest) {
HttpServletRequest httpRequest = (HttpServletRequest) request;
Integer code = (Integer) httpRequest.getAttribute("javax.servlet.error.status_code");
// If the request is for an error-page, use the request URL as the base URL.
// This avoids having wrong relative URLs for error page resources.
if (code != null) {
Url newBaseUrl = getRequest().getUrl();
urlRenderer.setBaseUrl(newBaseUrl);
}
}
return urlRenderer;
}
With this code, I get proper relative resource URLs. Are there any cases where this would not work? If not, could this form the basis of a simple fix of this issue without requiring the big rework mentioned by Igor? (at least for 1.5)
Note:
While investigating the same problem, I found this issue. To make the quickstart run, I had to modify pom.xml by removing the following lines :
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.15</version>
</dependency>
For some reason, this caused me a dependency problem with jmx...
was (Author: berniegp):
Here is a workaround I am now using. Add the following to your sub-class of RequestCycle (works in 1.5-RC7):
@Override
protected UrlRenderer newUrlRenderer() {
UrlRenderer urlRenderer = super.newUrlRenderer();
Object request = getRequest().getContainerRequest();
if (request instanceof HttpServletRequest) {
HttpServletRequest httpRequest = (HttpServletRequest) request;
Integer code = (Integer) httpRequest.getAttribute("javax.servlet.error.status_code");
// If the request is for an error-page, use the request URL as the base URL.
// This avoids having wrong relative URLs for error page resources.
if (code != null) {
Url newBaseUrl = getRequest().getUrl();
urlRenderer.setBaseUrl(newBaseUrl);
}
}
return urlRenderer;
}
With this code, I get proper relative resource URLs. Are there any cases where this would not work? If not, could this form the basis of a simple fix of this issue without requiring the big rework mentioned by Igor? (at least for 1.5)
Note:
While investigating the same problem, I found this issue. To make the quickstart run, I had to modify pom.xml by removing the following lines :
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.15</version>
</dependency>
For some reason, this caused me a dependency problem with jmx...
> 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
> Affects Versions: 1.5-RC3
> Environment: Tomcat 5
> Reporter: Sergiy Barlabanov
> Assignee: Igor Vaynberg
> Priority: Minor
> 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
[jira] [Commented] (WICKET-3602) Wrong relative URLs in an error
page during error dispatching when using non-empty context path or wicket
filter prefix
Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018808#comment-13018808 ]
Martin Grigorov commented on WICKET-3602:
-----------------------------------------
Yes, I also didn't find a way to fix this problem without reverting the improvement for WICKET-3551.
But as I said before in WICKET-3551: I wasn't able to reproduce the described problem there. It was working for me.
> 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
> 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
[jira] [Commented] (WICKET-3602) Wrong relative URLs in an error
page during error dispatching when using non-empty context path or wicket
filter prefix
Posted by "Bertrand Guay-Paquet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13095487#comment-13095487 ]
Bertrand Guay-Paquet commented on WICKET-3602:
----------------------------------------------
Here is a workaround I am now using. Add the following to your sub-class of RequestCycle (works in 1.5-RC7):
@Override
protected UrlRenderer newUrlRenderer() {
UrlRenderer urlRenderer = super.newUrlRenderer();
Object request = getRequest().getContainerRequest();
if (request instanceof HttpServletRequest) {
HttpServletRequest httpRequest = (HttpServletRequest) request;
Integer code = (Integer) httpRequest.getAttribute("javax.servlet.error.status_code");
// If the request is for an error-page, use the request URL as the base URL.
// This avoids having wrong relative URLs for error page resources.
if (code != null) {
Url newBaseUrl = getRequest().getUrl();
urlRenderer.setBaseUrl(newBaseUrl);
}
}
return urlRenderer;
}
With this code, I get proper relative resource URLs. Are there any cases where this would not work? If not, could this form the basis of a simple fix of this issue without requiring the big rework mentioned by Igor? (at least for 1.5)
Note:
While investigating the same problem, I found this issue. To make the quickstart run, I had to modify pom.xml by removing the following lines :
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.15</version>
</dependency>
For some reason, this caused me a dependency problem with jmx...
> 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
> Affects Versions: 1.5-RC3
> Environment: Tomcat 5
> Reporter: Sergiy Barlabanov
> Assignee: Igor Vaynberg
> Priority: Minor
> 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
[jira] [Updated] (WICKET-3602) Wrong relative URLs in an error page
during error dispatching when using non-empty context path or wicket filter
prefix
Posted by "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 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
[jira] [Commented] (WICKET-3602) Wrong relative URLs in an error
page during error dispatching when using non-empty context path or wicket
filter prefix
Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017911#comment-13017911 ]
Martin Grigorov commented on WICKET-3602:
-----------------------------------------
Patches are always welcome. Don't ask to provide them ;-)
Please also test the requirement in WICKET-3551 with your patch.
Thanks!
> 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
> 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
[jira] [Commented] (WICKET-3602) Wrong relative URLs in an error
page during error dispatching when using non-empty context path or wicket
filter prefix
Posted by "Bertrand Guay-Paquet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13095595#comment-13095595 ]
Bertrand Guay-Paquet commented on WICKET-3602:
----------------------------------------------
I had this problem so I tried a simple fix. Here is the 2 liner in org.apache.wicket.protocol.http.servlet.ServletWebRequest.getClientUrl():
Replace
if (errorAttributes != null && !Strings.isEmpty(errorAttributes.getRequestUri()))
{
return setParameters(Url.parse(errorAttributes.getRequestUri(), getCharset()));
}
with
if (errorAttributes != null && !Strings.isEmpty(errorAttributes.getRequestUri()))
{
final int start = httpServletRequest.getContextPath().length() + filterPrefix.length() +
1;
return setParameters(Url.parse(errorAttributes.getRequestUri().substring(start),
getCharset()));
}
This code does the same thing as the getUrl() method does, which is stripping the servlet context part. Are there any cases where this would not work? If not, could this be a simple fix of this issue without requiring the big rework mentioned by Igor? (at least for 1.5)
Note:
While investigating the same problem, I found this issue. To make the quickstart run, I had to modify pom.xml by removing the following lines :
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.15</version>
</dependency>
For some reason, this caused me a dependency problem with jmx...
> 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
> Affects Versions: 1.5-RC3
> Environment: Tomcat 5
> Reporter: Sergiy Barlabanov
> Assignee: Igor Vaynberg
> Priority: Minor
> 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
[jira] [Commented] (WICKET-3602) Wrong relative URLs in an error
page during error dispatching when using non-empty context path or wicket
filter prefix
Posted by "Sergiy Barlabanov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018899#comment-13018899 ]
Sergiy Barlabanov commented on WICKET-3602:
-------------------------------------------
it is reproducable on trunk with the quickstart app attached to this jira task. As I said, it works, if the application is deployed under root context ("/") and the filter mapping in web.xml is empty ("/*"). As soon, as filter mapping or non-empty context comes in play, it does not work.
> 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
> 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