On Thu, 2003-01-16 at 12:21, Stuart Donaldson wrote: > Ian, > One difference I found in the new algorithm vs old algorithm was when > passed a directory without a trailing '/' the old algorithm returns the > directory relying on dispatchRequest() to send a redirect. The new > algorithm treats it as a directory and finds the directory index. > > The rational the old algorithm gives, is that without the trailing '/' > relative url's would be messed up.
Hmm... that is correct. I'd rather leave it up to the servlet to deal with this, especially if we end up putting more stuff in the servlet anyway. Specifically, HTTPServlet can send a redirect, and Page can do like Zope, and put a <base href> in and avoid the redirect (or maybe do the redirect anyway, since that might be more reliable). > Also, if I understand the rational for the ExtraPathInfo setting, it seems > that with ExtraPathInfo and a directory index at the root of the context, or > a directory index at the root of the default context, you generally won't > get a 404 error. We walk up the URL looking for a servlet to handle the > request, and stop there. Yes, though that's not the current behavior (but it was the old behavior). But I can see times when it would be useful. > I think the ExtraPathInfo setting should be a servlet by servlet basis. > The servlet can choose to handle ExtraPathInfo information. If it does not > handle it, then a 404 error would result. If it does handle it, then things > proceed as normal. > > This could be implemented by simplifying the serverSideInfoForRequest*() > operation to always parse out the ExtraPathInfo. Then either > createServletInTransaction() or possible handleGoodURL() would ask the > servlet if it supported ExtraPathInfo, and if it did not, call the > handleBadURL. Again, agreed. Catching all 404s is a fairly extreme behavior, and I'd rather that only happen when it's specifically requested. But couldn't HTTPServlet do the checking itself? I think we should simplify Application, and put a bit more of the logic into HTTPServlet. I.e., ask forgiveness instead of permission. -- Ian Bicking Colorstudy Web Development [EMAIL PROTECTED] http://www.colorstudy.com PGP: gpg --keyserver pgp.mit.edu --recv-keys 0x9B9E28B7 4869 N Talman Ave, Chicago, IL 60625 / (773) 275-7241 ------------------------------------------------------- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en _______________________________________________ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
