Why not use a low level Valve to trap the HTTP call before a redirect can occur?
Jeff David Jencks wrote: > > On Apr 17, 2007, at 8:02 AM, Paul McMahan wrote: > >> Jarek and I have been struggling with an issue we encountered in >> Geronimo's TomcatEJBWebService that has to do with how EJB web >> services become URL addressable after they are deployed. You can see >> the full discussion here: >> https://issues.apache.org/jira/browse/GERONIMO-2841 >> >> In a nutshell, the basic problem is that when an HTTP client requests >> http://hostname/context Tomcat will automatically redirect the request >> to http://hostname/context/ (note the trailing slash). This behavior >> is mandated by section 9.10 of the servlet 2.4 specification which says: >> "A request URI of /foo will be redirected to a URI of /foo/" >> >> The reason this behavior causes a problem for our web services >> implementation is because when Geronimo's EJBWebServiceGBean deploys a >> web service it uses a context without the trailing slash, e.g. >> "/JAXWSBeanService/JAXWSBean". Then a web service client sends a POST >> request to that location, http://hostname/JAXWSBeanService/JAXWSBean, >> Since that URL corresponds to a context Tomcat responds with a >> redirect URL that appends the trailing slash. Jarek has found that >> this redirect causes a problem for web service clients because they >> will respond to it with a GET instead of a POST, thus losing the >> original method and structure of the request by the time it reaches >> the web services container. >> >> In case you're wondering, Jetty also exhibits this redirect behavior >> by default and Geronimo's JettyEJBWebService avoids it by overriding >> ContextHandler.handle(). But Tomcat implements this redirect behavior >> at the connector level and and I have not found any reasonable way to >> override it (maybe I am overlooking something). It used to be >> configurable but that support was explicitly removed: >> http://svn.apache.org/viewvc?view=rev&revision=298787 >> >> At this point we have identified the following options. Any feedback >> you can provide would be very helpful. >> >> 1.) Figure out some clever way to "outsmart" Tomcat and avoid the >> redirect behavior. I haven't found any way to do this but maybe >> someone else has an idea. Maybe this is not desirable since it >> arguably violates the servlet spec. >> 2.) Ask Tomcat to reimplement the configuration option they removed >> in rev 298787 that would allow us to avoid the redirect behavior. >> Again, maybe not desirable since it arguably violates the servlet spec. >> 3.) Redesign TomcatEJBWebService to deploy web services as servlets >> instead of contexts. This would be a significant design change and >> would also be inconsistent with our current implementation in Jetty. > > My guess is this is the best bet, but I couldn't figure out what context > root and servlet-mapping would apply to an ejb web service. Does > tomcat let you deploy a lot of apps at the same context-root? If so, > perhaps we can deploy each ejb-ws at "/" > > I'm not very worried about the tomcat implementation being different > from the jetty implementation. I'm more worried about this being a lot > of work. We might need to implement the tomcat object that runs > Digester to construct the servlet wrapper for us. > > thanks > david jencks > >> 4.) Expect web service clients to follow redirects more >> intelligently, i.e. respond to a redirect from a POST request with >> another POST instead of a GET. IIUC this may cause problems with TCK? >> (Jarek can elaborate). >> 5.) other ideas? >> >> >> Best wishes, >> Paul
