URLRewriteFilter Servlet Filter problem in WebSphere 6.1.0.5
I recently wrote up an article on SEO Friendly URL's for J2EE frameworks, while my tomcat implementations and WebSphere 5.1 implementations of the URLRewriteFilter were seemless, I ran into a problem on WebSphere 6.1 that caused me to rack my brain. The Output urls in the page were being rewritten fine, which is usually a gotcha if you forgot to response.encodeURL, but none of the inbound rules seemed to be rewriting back to the original url. In fact I was receiving a big fat 404 error and nothing in the console indicating that the URLRewrite Servlet Filter was not even being invoked. After several hours of Googling, I found that the guys over at Atlassian had run into the same problem with their products Jira and Confluence.
Apparently IBM made a change in 6.1.0.5 that is causing this problem:
WebSphere 6.1.0.5 and above checks if a URL is mapped to a servlet or a file before it puts a request through the filter chain. As we do not have a servlet or a file that is mapped to a URL:
http:///a/AZ/
WebSphere 6.1.0.5 sends a 404 to the user before giving the UrlRewrite filter a chance to redirect a URL to the correct place.
To make the filter invoke on a request without a servlet mapping you should be able to do the following in the WebSphere Admin Console:
- expand Servers -> Application Servers -> <server> -> Web Container Settings -> Web Container -> Custom Properties
- select New and then enter "com.ibm.ws.webcontainer.invokefilterscompatibility" as the property name and "true" as the value
- save the update and restart the server
Hopefully this explanation helps the WebSphere community with their SEO strategies by letting them rewrite their urls.
August 14th, 2008 - 03:20
Hello,
Thanks thanks thanks !!!!
We got the same problem of a new installation on your was application in 6.1.0.7
2 days to find the solution :s
September 18th, 2008 - 14:17
Do we have this issue with Websphere 6.0.0.1, here the application seems to work without a servlet mapping. but the same ear when deployed in WAS6.1, fails to detect the servlet , /servlet/Servletname. I provided the servlet mapping but still face the same issue. Does this have any connection with URLfilter or it is just an issue with classpath?
September 18th, 2008 - 14:37
Yes, you have to set the com.ibm.ws.webcontainer.invokefilterscompatibility to true in the Web Container, or it won’t pass the file through to the container.
October 10th, 2008 - 12:52
thanks.. it solved my problem
October 28th, 2008 - 10:49
I have the same problem.
I’m working with patch level 6.1.0.19 and after adding com.ibm.ws.webcontainer.invokefilterscompatibility property and restarting the service, I still have http error 404 with my servlets.
Same app deployed on 6.0 works fine (we are migrating from 6.0 to 6.1).
Any idea?
November 1st, 2008 - 17:25
@Eric Demasi – 6.1.0.19 should have the fix and should work fine as long as the property has been added in the right place in the WebContainer settings. If you have an http server make sure there are appropriate entries for your servlets in the plugin-config.xml.
July 17th, 2010 - 12:15
I have a servlet filter and wrapper that searches for certain values in the response html and replaces them if found. My wrapper uses a byteArray and it works fine on a weblogic server. However, on websphere, it is truncating the array, so the page is messed up. Do you have any idea why it might be truncated?
August 12th, 2010 - 18:54
Hi I have an issue,in WAS6.1 while i am trying to open the homepage it is redirecting to another page, here ssl enabled.
please provide me a solution for this.
Thanks.
Sid.
April 25th, 2011 - 07:47
This was a big help. Thanks!
August 8th, 2011 - 05:48
Thanks!!!
We are in a migration an application from WAS5 to WAS6, in 5 everything worked, in WAS6, everything worked except a filter /* that should be executed always (even if pages didn’t exist). Thanks to this blog, you saved me at least 2 days of headacke!!
February 3rd, 2012 - 13:48
Thank you very much, this really helped me to fix my issue.