On Wed, 18 Aug 2004 15:13:53 -0400, Dan Allen <[EMAIL PROTECTED]> wrote: > Before I go paging through the J2EE spec to find a defense, I want to > see if someone out there can offer advice in the following matter. In > our application, the configuration of the servers is such that any URL > with a context of "/apps/" is captured by the webserver, the URL is > rewritten with this context stripped and the resulting URL is passed > internally to the J2EE application server. For all intents and > purposes, the app server assumes that the URL requested was without > the "/apps/" context and processes the servlet mapping as such. > However, when the taglibs generate URLs, the "/apps/" portion is not > prepended and therefore a followup request by the client will not be > processed by the app server. Is this in violation of the J2EE spec > for the webserver to alter the URLs in this way? > > client > (requests http://hostname/apps/modulename/) > webserver > (rewrites internally to http://hostname/modulename/) > app server > (generates http://hostname/modulename/somefile.jsp) > client > (requests http://hostname/modulename/somefile.jsp) > webserver > (throws 404 error) > > Dan >
See Section SRV.4.4 of the Servlet Spec. In brief, and modulo URL encoding differences, the following equation is required to be true: requestURI = contextPath + servletPath + pathInfo where requestURI is the portion of the URL after the host and port. *All* servlet-API based technologies (including Struts, and including tag libraries) rely on this equation being true so that they can construct URIs to other resources in the same web application. Therefore, an app server (which includes a front-end proxy if you're using one) that lies to you, as in your scenario above, is broken. You should investigate configuration settings in your server that would let you compensate for this sort of thing, so that the request URI seen by the application properly reflects the one that the client sent, not the one that was internally passed from the proxy. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
