Listers,
I've identified that performing a redirection in Tomcat breaks a specific Remedy Knowledge Management function. We have a requirement to allow an end user to enter the following: https://<servername> as a URL and be redirected to https://<servername>/arsys/home. This is more or less a convenience requirement. I've done this under IIS before with no issues. We've since moved to MidTier 7.1 under Tomcat standalone and I've performed the above by modifying index.html under Tomcat\webapps\ROOT as follows: <html> <head> <meta http-equiv="refresh" content="0;URL=https://<servername>arsys/home"> </head> <body> </body> </html> This too has the desired result as the end user can simply enter https://<servername> and get to the Remedy login page without issue. The issue by doing this is that it breaks RKM's ability to embed images or attach files to documents. I used the Fiddler application to trace what was going on after setting Tomcat back to regular non-SSL HTTP and saw HTTP 302 errors being thrown when attempting to perform the attachment or image insertion functions. HTTP 302 means that the server is redirecting the user somewhere else to get the content. From an end user's perspective, all is well until they attempt to attach a file or insert an image. Upon performing either of these functions, they simply don't work. When attempting to attach a file, "nothing happens". When attempting to insert an image, a "red X" is displayed. This is something you might encounter on a site with a broken URL to an image. After getting nowhere with BMC support on this, some Google'ing revealed the following: "If myapp is a directory (not a web application), Tomcat will send a 302 Error to redirect your browser to http://localhost:8080/myapp/index.jsp. This is completely invisible to the user, so everything looks fine. The problem really occurs if your JSP handles username/password authentication i.e. http://username:[EMAIL PROTECTED]:8080/myapp What happens is that Tomcat will send a 302 to redirect the browser to http://localhost:8080/myapp/index.jsp ... which the browser delightfully does, but upon redirection, the browser doesn't associate the "username:password" portion with the new URL (possibly due to security issues). So if your index.jsp is handling the authenticate protocol, the browser will pop up a diaglog prompting the user for username/password instead of just logging in as it should." So, when the user attempts to embed an image or add an attachment to an RKM article, their credentials are being stripped and you can see references to an AccessDenied servlet in the Tomcat logs. Therefore, the attempt to attach a file or insert an image silently fails. My question is this: Is there a method to perform the desired redirection that won't effect RKM in the manner described above? I've resorted to abandoning the redirection and, after clearing the cache and restarting Tomcat, the issue goes away. When reinstating the redirection method above, the issue returns. Any ideas? Ben _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
