Stuart Donaldson [mailto:stuartd@...] wrote:
> 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
> 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
> 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
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...