DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4462>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4462 Websphere causes ALL forwards with redirect=true to break Summary: Websphere causes ALL forwards with redirect=true to break Product: Struts Version: 1.0 Final Platform: Other URL: http://www- 1.ibm.com/servlet/support/manager?rs=180&rt=0&org=SW&doc =1005783 OS/Version: All Status: NEW Severity: Major Priority: Other Component: Controller AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Unfortunately, in IBM WebSphere the lines: path = request.getContextPath() + path; response.sendRedirect( response.encodeRedirectURL( path ) ); in the ActionServlet does not work. The cause of this, ruling out the lineage and possible severe brain damage of IBM developers, is that IBM prepends the current web app's path to the redirect URL when the URL begins with "/". In fact, IBM thinks that this is a feature. Though this is not really a bug in struts it becomes impossible to work around without modifying the ActionServlet. This is hardly a viable option for us, because our client has a large IT department riddled with bureacracy and is quite afraid of the ramnifications of modifying existing software packages. Please respond to this as soon as you can, because this is an important issue for our company. The organization we are developing for is considering the use of struts in its future internal and external java projects, which would probably be numerous. We are using IBM WebSphere 3.5.3. If you need to contact me over the weekend, an alternate e-mail is [EMAIL PROTECTED] . Thanks, Joe Khoobyar ---- Quote from IBM's site below ---- 1. Prior to 3.022, developers had to put the full web path for their resource in the sendRedirect call. In 3.022 and later, WebSphere correctly prepends the current web app path to the given uri. This means that sendRedirect("/myapp/mypage.jsp") will resolve to " http://myhost/myapp/myapp/mypage.jsp " (if the current web path is "myapp") and (probably) generate a page-not-found error. The workaround is to change application code to remove the app path from the uri, or to add a new web app path (in this example "/myapp/myapp") to the web application to "fake out" WebSphere into serving the uri.