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. 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. 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. Stuart Donaldson Alerton Technologies Inc. ------------------------------------------------------- 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
