You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Jeremy Thomerson (JIRA)" <ji...@apache.org> on 2010/12/16 23:43:02 UTC
[jira] Created: (WICKET-3258) Allow for non-relative redirects for
buggy servlet containers
Allow for non-relative redirects for buggy servlet containers
-------------------------------------------------------------
Key: WICKET-3258
URL: https://issues.apache.org/jira/browse/WICKET-3258
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 1.5-M3, 1.4.14
Environment: Websphere
Reporter: Jeremy Thomerson
Assignee: Jeremy Thomerson
Priority: Minor
There appears to be a bug in the way WebSphere handles relative URLs. The servlet spec (http://jcp.org/aboutJava/communityprocess/final/jsr154/index.html), page 260 specifies the behavior for relative URLs, which Wicket uses, but WebSphere appears to ignore. If we send a relative URL like "../../Something.html" to HttpServletResponse#sendRedirect, the relative path should be relative *to the requested URI* (the page I was requesting that resulted in the redirect). WebSphere isn't implementing this behavior correctly. Instead, it appears to interpret it as relative *to the app context and servlet mapping*.
More details:
We request a page like:
http://[server]:[serverport]/[appcontext]/[servletmapping]/somefolder/someotherfolder/foo.html
That page results in an error, and Wicket tries to redirect to an unmounted bookmarkable page by doing sendRedirect("../../?wicket:bookmarkablePage=:com.FooPage"). This is correct according to the servlet spec, because the url passed to sendRedirect should be relative *to the requested URI* (<--- this is the key). So, we expect the container to redirect to http://[server]:[serverport]/[appcontext]/[servletmapping]/?wicket:bookmarkable=com.FooPage . Jetty does (and Tomcat and others). But, WebSphere does not.
Although I cannot look at the Websphere code, I suspect that it is interpreting this relative URL as being relative to the root of the servlet mapping. It is then removing two folders, which takes us back to the server root (instead of the servlet mapping, like it should), removing the app context and servlet mapping (i.e. http://[server]:[serverport]/?wicket:bookmarkable=com.FooPage) This is obviously incorrect.
We have tried this compatibility setting (true and false), but it didn't work: https://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/xrun_jvm_sendredirect.html
There are a lot of reports about the problem:
http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg68864.html
https://issues.apache.org/jira/browse/STR-1843?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel
http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg06308.html
Although we obviously can't fix the issue, we should provide a way for users of these servlet containers to redirect to an absolute URL rather than a relative URL.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3258) Allow for non-relative redirects
for buggy servlet containers
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972309#action_12972309 ]
Hudson commented on WICKET-3258:
--------------------------------
Integrated in Apache Wicket 1.4.x #336 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/336/])
> Allow for non-relative redirects for buggy servlet containers
> -------------------------------------------------------------
>
> Key: WICKET-3258
> URL: https://issues.apache.org/jira/browse/WICKET-3258
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.4.14, 1.5-M3
> Environment: Websphere
> Reporter: Jeremy Thomerson
> Assignee: Jeremy Thomerson
> Priority: Minor
> Attachments: relativeurlproblem.tar.gz
>
>
> There appears to be a bug in the way WebSphere handles relative URLs. The servlet spec (http://jcp.org/aboutJava/communityprocess/final/jsr154/index.html), page 260 specifies the behavior for relative URLs, which Wicket uses, but WebSphere appears to ignore. If we send a relative URL like "../../Something.html" to HttpServletResponse#sendRedirect, the relative path should be relative *to the requested URI* (the page I was requesting that resulted in the redirect). WebSphere isn't implementing this behavior correctly. Instead, it appears to interpret it as relative *to the app context and servlet mapping*.
>
> More details:
>
> We request a page like:
> http://[server]:[serverport]/[appcontext]/[servletmapping]/somefolder/someotherfolder/foo.html
>
> That page results in an error, and Wicket tries to redirect to an unmounted bookmarkable page by doing sendRedirect("../../?wicket:bookmarkablePage=:com.FooPage"). This is correct according to the servlet spec, because the url passed to sendRedirect should be relative *to the requested URI* (<--- this is the key). So, we expect the container to redirect to http://[server]:[serverport]/[appcontext]/[servletmapping]/?wicket:bookmarkable=com.FooPage . Jetty does (and Tomcat and others). But, WebSphere does not.
>
> Although I cannot look at the Websphere code, I suspect that it is interpreting this relative URL as being relative to the root of the servlet mapping. It is then removing two folders, which takes us back to the server root (instead of the servlet mapping, like it should), removing the app context and servlet mapping (i.e. http://[server]:[serverport]/?wicket:bookmarkable=com.FooPage) This is obviously incorrect.
>
> We have tried this compatibility setting (true and false), but it didn't work: https://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/xrun_jvm_sendredirect.html
>
> There are a lot of reports about the problem:
> http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg68864.html
> https://issues.apache.org/jira/browse/STR-1843?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel
> http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg06308.html
> Although we obviously can't fix the issue, we should provide a way for users of these servlet containers to redirect to an absolute URL rather than a relative URL.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] [Commented] (WICKET-3258) Allow for non-relative redirects
for buggy servlet containers
Posted by "Jeremy Thomerson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453255#comment-13453255 ]
Jeremy Thomerson commented on WICKET-3258:
------------------------------------------
[~oscar.huarte] - I fixed this while on-site for a customer that used WAS. I don't use it personally. Since it was nearly two years ago, I don't remember all the details, but I think that the description above and the comments in the code commited is quite thorough. See https://fisheye6.atlassian.com/changelog/wicket?cs=1050204 for more information on how to override the default Wicket behavior to send an absolute URL redirect instead of relative, thus negating the poor calculation of a relative URL by WAS.
> Allow for non-relative redirects for buggy servlet containers
> -------------------------------------------------------------
>
> Key: WICKET-3258
> URL: https://issues.apache.org/jira/browse/WICKET-3258
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.4.14, 1.5-M3
> Environment: Websphere
> Reporter: Jeremy Thomerson
> Assignee: Jeremy Thomerson
> Priority: Minor
> Fix For: 1.4.18, 1.5.0
>
> Attachments: relativeurlproblem.tar.gz
>
>
> There appears to be a bug in the way WebSphere handles relative URLs. The servlet spec (http://jcp.org/aboutJava/communityprocess/final/jsr154/index.html), page 260 specifies the behavior for relative URLs, which Wicket uses, but WebSphere appears to ignore. If we send a relative URL like "../../Something.html" to HttpServletResponse#sendRedirect, the relative path should be relative *to the requested URI* (the page I was requesting that resulted in the redirect). WebSphere isn't implementing this behavior correctly. Instead, it appears to interpret it as relative *to the app context and servlet mapping*.
>
> More details:
>
> We request a page like:
> http://[server]:[serverport]/[appcontext]/[servletmapping]/somefolder/someotherfolder/foo.html
>
> That page results in an error, and Wicket tries to redirect to an unmounted bookmarkable page by doing sendRedirect("../../?wicket:bookmarkablePage=:com.FooPage"). This is correct according to the servlet spec, because the url passed to sendRedirect should be relative *to the requested URI* (<--- this is the key). So, we expect the container to redirect to http://[server]:[serverport]/[appcontext]/[servletmapping]/?wicket:bookmarkable=com.FooPage . Jetty does (and Tomcat and others). But, WebSphere does not.
>
> Although I cannot look at the Websphere code, I suspect that it is interpreting this relative URL as being relative to the root of the servlet mapping. It is then removing two folders, which takes us back to the server root (instead of the servlet mapping, like it should), removing the app context and servlet mapping (i.e. http://[server]:[serverport]/?wicket:bookmarkable=com.FooPage) This is obviously incorrect.
>
> We have tried this compatibility setting (true and false), but it didn't work: https://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/xrun_jvm_sendredirect.html
>
> There are a lot of reports about the problem:
> http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg68864.html
> https://issues.apache.org/jira/browse/STR-1843?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel
> http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg06308.html
> Although we obviously can't fix the issue, we should provide a way for users of these servlet containers to redirect to an absolute URL rather than a relative URL.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-3258) Allow for non-relative redirects
for buggy servlet containers
Posted by "Adam Lewandowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453038#comment-13453038 ]
Adam Lewandowski commented on WICKET-3258:
------------------------------------------
I also saw this problem with Websphere 8 (and 6 and 7), although in a slightly different context: redirects to mounted bookmarkable pages. There are a couple of odd/non-standard behaviors in WAS that cause this:
1) When the request is not handled by a registered servlet (as is usually the case when using the Wicket filter), then WAS considers the request to be handled by a default servlet with a servlet mapping of "" (empty string). It considers the entire request path after the context root to be 'path info'. So request.getServletPath() returns "" and getPathInfo() returns the full context-relative path.This is exactly the opposite of what every other container (including the reference implementation) does.
2) When calculating a relative URL for redirect, WAS is stripping the 'path info' off of the request path and tacking on the relative portion. Because WAS considers the entire request path to be 'path info', this results in the redirect URL being relative to the context root, instead of the request URI. I did discover an undocumented custom property ('com.ibm.ws.webcontainer.redirectwithpathinfo') that, when set to true, makes it behave according to spec: “If the location is relative without a leading '/' the container interprets it as relative to the current request URI”.
I didn't fully test with the custom property, but it did appear to be working correctly in my limited testing. Instead we opted to use a different rendering strategy (ONE_PASS_RENDER) to eliminate the problematic redirects in the first place.
> Allow for non-relative redirects for buggy servlet containers
> -------------------------------------------------------------
>
> Key: WICKET-3258
> URL: https://issues.apache.org/jira/browse/WICKET-3258
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.4.14, 1.5-M3
> Environment: Websphere
> Reporter: Jeremy Thomerson
> Assignee: Jeremy Thomerson
> Priority: Minor
> Fix For: 1.4.18, 1.5.0
>
> Attachments: relativeurlproblem.tar.gz
>
>
> There appears to be a bug in the way WebSphere handles relative URLs. The servlet spec (http://jcp.org/aboutJava/communityprocess/final/jsr154/index.html), page 260 specifies the behavior for relative URLs, which Wicket uses, but WebSphere appears to ignore. If we send a relative URL like "../../Something.html" to HttpServletResponse#sendRedirect, the relative path should be relative *to the requested URI* (the page I was requesting that resulted in the redirect). WebSphere isn't implementing this behavior correctly. Instead, it appears to interpret it as relative *to the app context and servlet mapping*.
>
> More details:
>
> We request a page like:
> http://[server]:[serverport]/[appcontext]/[servletmapping]/somefolder/someotherfolder/foo.html
>
> That page results in an error, and Wicket tries to redirect to an unmounted bookmarkable page by doing sendRedirect("../../?wicket:bookmarkablePage=:com.FooPage"). This is correct according to the servlet spec, because the url passed to sendRedirect should be relative *to the requested URI* (<--- this is the key). So, we expect the container to redirect to http://[server]:[serverport]/[appcontext]/[servletmapping]/?wicket:bookmarkable=com.FooPage . Jetty does (and Tomcat and others). But, WebSphere does not.
>
> Although I cannot look at the Websphere code, I suspect that it is interpreting this relative URL as being relative to the root of the servlet mapping. It is then removing two folders, which takes us back to the server root (instead of the servlet mapping, like it should), removing the app context and servlet mapping (i.e. http://[server]:[serverport]/?wicket:bookmarkable=com.FooPage) This is obviously incorrect.
>
> We have tried this compatibility setting (true and false), but it didn't work: https://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/xrun_jvm_sendredirect.html
>
> There are a lot of reports about the problem:
> http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg68864.html
> https://issues.apache.org/jira/browse/STR-1843?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel
> http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg06308.html
> Although we obviously can't fix the issue, we should provide a way for users of these servlet containers to redirect to an absolute URL rather than a relative URL.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WICKET-3258) Allow for non-relative redirects for
buggy servlet containers
Posted by "Jeremy Thomerson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Thomerson updated WICKET-3258:
-------------------------------------
Attachment: relativeurlproblem.tar.gz
if you run this in jetty, everything is fine. if you run it (or a very similar project) in websphere, it fails
> Allow for non-relative redirects for buggy servlet containers
> -------------------------------------------------------------
>
> Key: WICKET-3258
> URL: https://issues.apache.org/jira/browse/WICKET-3258
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.4.14, 1.5-M3
> Environment: Websphere
> Reporter: Jeremy Thomerson
> Assignee: Jeremy Thomerson
> Priority: Minor
> Attachments: relativeurlproblem.tar.gz
>
>
> There appears to be a bug in the way WebSphere handles relative URLs. The servlet spec (http://jcp.org/aboutJava/communityprocess/final/jsr154/index.html), page 260 specifies the behavior for relative URLs, which Wicket uses, but WebSphere appears to ignore. If we send a relative URL like "../../Something.html" to HttpServletResponse#sendRedirect, the relative path should be relative *to the requested URI* (the page I was requesting that resulted in the redirect). WebSphere isn't implementing this behavior correctly. Instead, it appears to interpret it as relative *to the app context and servlet mapping*.
>
> More details:
>
> We request a page like:
> http://[server]:[serverport]/[appcontext]/[servletmapping]/somefolder/someotherfolder/foo.html
>
> That page results in an error, and Wicket tries to redirect to an unmounted bookmarkable page by doing sendRedirect("../../?wicket:bookmarkablePage=:com.FooPage"). This is correct according to the servlet spec, because the url passed to sendRedirect should be relative *to the requested URI* (<--- this is the key). So, we expect the container to redirect to http://[server]:[serverport]/[appcontext]/[servletmapping]/?wicket:bookmarkable=com.FooPage . Jetty does (and Tomcat and others). But, WebSphere does not.
>
> Although I cannot look at the Websphere code, I suspect that it is interpreting this relative URL as being relative to the root of the servlet mapping. It is then removing two folders, which takes us back to the server root (instead of the servlet mapping, like it should), removing the app context and servlet mapping (i.e. http://[server]:[serverport]/?wicket:bookmarkable=com.FooPage) This is obviously incorrect.
>
> We have tried this compatibility setting (true and false), but it didn't work: https://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/xrun_jvm_sendredirect.html
>
> There are a lot of reports about the problem:
> http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg68864.html
> https://issues.apache.org/jira/browse/STR-1843?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel
> http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg06308.html
> Although we obviously can't fix the issue, we should provide a way for users of these servlet containers to redirect to an absolute URL rather than a relative URL.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] [Resolved] (WICKET-3258) Allow for non-relative redirects
for buggy servlet containers
Posted by "Jeremy Thomerson (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Thomerson resolved WICKET-3258.
--------------------------------------
Resolution: Fixed
Fix Version/s: 1.4.18
1.5.0
This was fixed quite a long time ago and apparently I left it open until I could make sure it was also addressed in 1.5.x... Well, it got lost in my backlog and after just finding it I verified that there is a way to compensate for it in 1.5.x as well, so I can close it.
> Allow for non-relative redirects for buggy servlet containers
> -------------------------------------------------------------
>
> Key: WICKET-3258
> URL: https://issues.apache.org/jira/browse/WICKET-3258
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.4.14, 1.5-M3
> Environment: Websphere
> Reporter: Jeremy Thomerson
> Assignee: Jeremy Thomerson
> Priority: Minor
> Fix For: 1.5.0, 1.4.18
>
> Attachments: relativeurlproblem.tar.gz
>
>
> There appears to be a bug in the way WebSphere handles relative URLs. The servlet spec (http://jcp.org/aboutJava/communityprocess/final/jsr154/index.html), page 260 specifies the behavior for relative URLs, which Wicket uses, but WebSphere appears to ignore. If we send a relative URL like "../../Something.html" to HttpServletResponse#sendRedirect, the relative path should be relative *to the requested URI* (the page I was requesting that resulted in the redirect). WebSphere isn't implementing this behavior correctly. Instead, it appears to interpret it as relative *to the app context and servlet mapping*.
>
> More details:
>
> We request a page like:
> http://[server]:[serverport]/[appcontext]/[servletmapping]/somefolder/someotherfolder/foo.html
>
> That page results in an error, and Wicket tries to redirect to an unmounted bookmarkable page by doing sendRedirect("../../?wicket:bookmarkablePage=:com.FooPage"). This is correct according to the servlet spec, because the url passed to sendRedirect should be relative *to the requested URI* (<--- this is the key). So, we expect the container to redirect to http://[server]:[serverport]/[appcontext]/[servletmapping]/?wicket:bookmarkable=com.FooPage . Jetty does (and Tomcat and others). But, WebSphere does not.
>
> Although I cannot look at the Websphere code, I suspect that it is interpreting this relative URL as being relative to the root of the servlet mapping. It is then removing two folders, which takes us back to the server root (instead of the servlet mapping, like it should), removing the app context and servlet mapping (i.e. http://[server]:[serverport]/?wicket:bookmarkable=com.FooPage) This is obviously incorrect.
>
> We have tried this compatibility setting (true and false), but it didn't work: https://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/xrun_jvm_sendredirect.html
>
> There are a lot of reports about the problem:
> http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg68864.html
> https://issues.apache.org/jira/browse/STR-1843?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel
> http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg06308.html
> Although we obviously can't fix the issue, we should provide a way for users of these servlet containers to redirect to an absolute URL rather than a relative URL.
--
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] [Commented] (WICKET-3258) Allow for non-relative redirects
for buggy servlet containers
Posted by "Oscar Che (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13282240#comment-13282240 ]
Oscar Che commented on WICKET-3258:
-----------------------------------
Hi Jeremy,
I met this problem by using wicket 1.5.4 with websphere 8.0.2. Do you have any solution to resolve this issue? I have searched the problem but still cannot a way to get it sovled. Thanks for your time, and I do appreciate of it if you can give me a hint.
Many Thanks,
Oscar
> Allow for non-relative redirects for buggy servlet containers
> -------------------------------------------------------------
>
> Key: WICKET-3258
> URL: https://issues.apache.org/jira/browse/WICKET-3258
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.4.14, 1.5-M3
> Environment: Websphere
> Reporter: Jeremy Thomerson
> Assignee: Jeremy Thomerson
> Priority: Minor
> Fix For: 1.4.18, 1.5.0
>
> Attachments: relativeurlproblem.tar.gz
>
>
> There appears to be a bug in the way WebSphere handles relative URLs. The servlet spec (http://jcp.org/aboutJava/communityprocess/final/jsr154/index.html), page 260 specifies the behavior for relative URLs, which Wicket uses, but WebSphere appears to ignore. If we send a relative URL like "../../Something.html" to HttpServletResponse#sendRedirect, the relative path should be relative *to the requested URI* (the page I was requesting that resulted in the redirect). WebSphere isn't implementing this behavior correctly. Instead, it appears to interpret it as relative *to the app context and servlet mapping*.
>
> More details:
>
> We request a page like:
> http://[server]:[serverport]/[appcontext]/[servletmapping]/somefolder/someotherfolder/foo.html
>
> That page results in an error, and Wicket tries to redirect to an unmounted bookmarkable page by doing sendRedirect("../../?wicket:bookmarkablePage=:com.FooPage"). This is correct according to the servlet spec, because the url passed to sendRedirect should be relative *to the requested URI* (<--- this is the key). So, we expect the container to redirect to http://[server]:[serverport]/[appcontext]/[servletmapping]/?wicket:bookmarkable=com.FooPage . Jetty does (and Tomcat and others). But, WebSphere does not.
>
> Although I cannot look at the Websphere code, I suspect that it is interpreting this relative URL as being relative to the root of the servlet mapping. It is then removing two folders, which takes us back to the server root (instead of the servlet mapping, like it should), removing the app context and servlet mapping (i.e. http://[server]:[serverport]/?wicket:bookmarkable=com.FooPage) This is obviously incorrect.
>
> We have tried this compatibility setting (true and false), but it didn't work: https://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/xrun_jvm_sendredirect.html
>
> There are a lot of reports about the problem:
> http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg68864.html
> https://issues.apache.org/jira/browse/STR-1843?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel
> http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg06308.html
> Although we obviously can't fix the issue, we should provide a way for users of these servlet containers to redirect to an absolute URL rather than a relative URL.
--
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