No, if you use img="/foo.gif" then '/' ALWAYS indicates to the browser to request it from the domain root.
> -----Original Message----- > From: Alan Weissman [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 21, 2004 1:26 PM > To: 'Tomcat Users List' > Subject: RE: ServletRequest's path elements not updated by > calls to getRequestDispatcher() > > > You are so right Mike, thanks so much. > > Well I guess now my problem is that for requests ending in > /target, my img tags need to look like "/images/image.gif" > wheras for requests ending in > /target/ my img tags need to look like "../images/image.gif". > > I can't imagine I'm the first person to try to implement this > kind of functionality. Any other strategies out there? I'm > debating rewriting the defaultServlet at this point. > > Thanks again, > Alan > > -----Original Message----- > From: Mike Curwen [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 21, 2004 2:19 PM > To: 'Tomcat Users List' > Subject: RE: ServletRequest's path elements not updated by calls to > getRequestDispatcher() > > That's the request dispatcher. Images and CSS are all > 'called' from the client and have nothing to do with the dispatcher. > > If you type in http://www.foo.com/target > then to the browser, the resource requested is 'target' > and your image and css links, if they're relative, are going > to be relative to www.foo.com > > If, OTOH, you ask for http://www.foo.com/target/ > then to your browser, you appear to be requesting a resouce > in the /target directory, and so images/css will be requested > from there. > > The simplest answer is: > > replace "img=foo.gif" > with "img=/foo.gif" > > > > > -----Original Message----- > > From: Alan Weissman [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, January 21, 2004 1:11 PM > > To: Tomcat Users List > > Subject: ServletRequest's path elements not updated by calls > > to getRequestDispatcher() > > > > > > Hi Everyone - > > > > I have a requirement to allow for URLs on a site of the > > format www.site.com/target where 'target' is not a real > > directory or servlet, but redirects to another page on the site. > > > > To handle this, I have developed a ServletFilter which takes > > the 'target' off the URL and attempts to do a server side > > forward to a servlet using the RequestDispatcher. This is > > working for www.site.com/target. I can get the > > RequestDispatcher from either the ServletRequest or the > > ServletContext and redirect to any target servlet with forward(). > > > > The problem arises where I try to handle www.site.com/target/ > > (note the trailing slash). In this case, the > > RequestDispatcher forwards to the target correctly HOWEVER, > > all subsequent HTTP GETs for images, css, etc, are being > > attempted on the wrong directory, /target/. This seems to be > > because the ServletRequest doesn't seem to adjust its path > > elements accordingly. For instance, if /target/ is supposed > > to redirect to target.jsp using forward("/target.jsp") the > > requests look like: > > > www.site.com/target.jsp > www.site.com/target/image.gif > www.site.com/target/style.css > > Of course, /target was never a real directory to begin with :) > > Now, According to the API doc for RequestDispatcher: > > "For a RequestDispatcher obtained via getRequestDispatcher(), > the ServletRequest object has its path elements and > parameters adjusted to match the path of the target resource. " > > Does anyone have any experience with this issue? Is this a > bug? Is there a workaround? > > Thanks so much, > Alan > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
