https://issues.apache.org/bugzilla/show_bug.cgi?id=50026
--- Comment #8 from Tim Whittington <t...@apache.org> 2010-10-04 16:09:02 EDT 
---
(In reply to comment #5)
> Some random thoughts:
> - The default Servlet doesn't *need* to support serving content from an
> arbitrary mapping. The user can just move the static content in the web-app to
> the desired location

Agreed, although it's a breaking change for people using it now.
I can't see the sense in re-mounting your entire webapp under a sub-path
(except for WebDAV, where you want to sandbox the capabilities).

> - The WebDAV Servlet (that extends the Default Servlet) does need to do this
> and I suspect is the reason for just using getPathInfo() and not
> getServletPath() + getPathInfo()

The WebDAV Servlet already uses getPathInfo() explicitly, so won't be affected
by this change.
It does suffer from exposing WEB-INF though, as it delegates GET requests to
DefaultServlet.

> - We don't, currently, support configuring the Default Servlet for a sub-set 
> of
> the application's URL space (without using a sub-context). Chuck's proposed
> change would support this. Need to think about the implications for WebDAV.

I can't see any major implications - I've tested with a combination of WebDAV
mounted to subpath, WebDAV mounted to /*, and DefaultServlet mounted to / and a
subpath, and all looks to work OK.

> I'm leaning towards making Chuck's proposed change for the Default Servlet and
> over-riding that in the WebDAV Servlet to restore the current behaviour.

+1, except that it's already overridden.

I'll commit some fixes to DefaultServlet and WebdavServlet, get some review and
then propose changes for 6.0.x and perhaps 5.5.x.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to