Stuart Donaldson [mailto:[EMAIL PROTECTED]] 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.

Yes, it sounds like the new algorithm will break relative links because of
this.

>  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.

It would be great for ExtraPathInfo to be selectable on a servlet-by-servlet
basis, but if it's a lot harder to do I'd hold off until a future release.
But if you think you know how to do it easily, go for it...

- Geoff


-------------------------------------------------------
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

Reply via email to