Allow DispatcherServlet/ServletWrappingController to work with the extended WebDAV methods [SPR-4799]

[spring-projects-issues]

Antonio Mota opened SPR-4799 and commented

The DispatcherServlet doesn't allow methods beside HTTP one's, thus disabling the use in WebDAV contexts. This can be corrected by override one method in DispatcherServlet, as discussed in http://forum.springframework.org/showthread.php?t=53472 :

protected void service(HttpServletRequest req, HttpServletResponse resp)
		throws ServletException, java.io.IOException {
	try {
		doService(req, resp);
	} catch (Exception e) {
		// TODO 
	}
}

Also, ServletWrappingController could have a constructor to allow the WebDAV methods to be forward to a WevDAV servlet:

public ServletWrappingController() {

	String[] m = { "OPTIONS", "GET", "HEAD", "POST", "TRACE", "PROPFIND",
			"PROPPATCH", "MKCOL", "COPY", "PUT", "DELETE", "MOVE", "LOCK",
			"UNLOCK", "VERSION-CONTROL" };

	setSupportedMethods(m);

}

or even better, issuing a OPTIONS to the wrapped servlet and setting the supported methods to it's result .

---

Issue Links:

• Regression: HttpEntityMethodProcessor does not allow other Http methods than defined in the HttpMethod Enum [SPR-13776] #18350 Regression: HttpEntityMethodProcessor does not allow other Http methods than defined in the HttpMethod Enum ("depends on")
• Add support for the HTTP PATCH method [SPR-7985] #12640 Add support for the HTTP PATCH method
• RequestMethodsRequestCondition fails on unsupported method types [SPR-9815] #14448 RequestMethodsRequestCondition fails on unsupported method types

Referenced from: commits 3d87718

2 votes, 5 watchers

[spring-projects-issues]

bugmenot commented

Also see <code>FrameworkServlet.setDispatchOptionsRequest(boolean)</code>: sets whether servlet should dispatch an HTTP OPTIONS request to the doService method. (DispatcherServlet extends FrameworkServlet)

[spring-projects-issues]

bugmenot commented

Also affects ServletForwardingController (obviously!)

[spring-projects-issues]

bugmenot commented

Possibly better to call 'processRequest(req, resp)' instead of 'doService(req, resp)'.

[spring-projects-issues]

Rossen Stoyanchev commented

This issue has been resolved through a selective bulk update, as part of a larger effort to better manage unresolved issues. To qualify for the update, the issue was either created before Spring 3.0 or affects a version older than Spring 3.0 and is not a bug.

There is a good chance the request was made obsolete, or at least partly outdated, by changes in later versions of Spring including deprecations. It is also possible it didn't get enough traction or we didn't have enough time to address it. One way or another, we didn't get to it.

If you believe the issue, or some aspects of it, are still relevant and worth pursuing at present you may re-open this issue or create a new one with a more up-to-date description.

We thank you for your contributions and encourage you to become familiar with the current process of managing Spring Framework JIRA issues that has been in use for over a year.

[spring-projects-issues]

Juergen Hoeller commented

As of the upcoming 4.3.0.BUILD-SNAPSHOT, DispatcherServlet and ServletWrappingController / ServletForwardingController accept any HTTP method by default. This leaves it up to the target controller/servlet to reject an HTTP method that it cannot deal with.

Juergen

[spring-projects-issues]

Johannes Edmeier commented

Currnenlty (4.3.2) the AbstractController handles the OPTIONS request itself. In my case I need to forward the OPTIONS request to a ZuulServlet which forwards the request to an external service. I wonder if it's possible to dispatch the OPTIONS request to the wrapped servlet itself like the DispatcherServlet is able to do.