This is in line with the current behavior of HttpServlet that would
have been in used with dispatchOptionsRequest on the DispatcherSerlvet
set to false (the default prior to 4.3).
Issue: SPR-13130
@ -317,8 +317,11 @@ public abstract class RequestMappingInfoHandlerMapping extends AbstractHandlerMe
@@ -317,8 +317,11 @@ public abstract class RequestMappingInfoHandlerMapping extends AbstractHandlerMe
@ -112,7 +112,7 @@ public class ResourceHttpRequestHandler extends WebContentGenerator
@@ -112,7 +112,7 @@ public class ResourceHttpRequestHandler extends WebContentGenerator
@ -226,6 +226,11 @@ public class ResourceHttpRequestHandler extends WebContentGenerator
@@ -226,6 +226,11 @@ public class ResourceHttpRequestHandler extends WebContentGenerator
@ -237,11 +242,6 @@ public class ResourceHttpRequestHandler extends WebContentGenerator
@@ -237,11 +242,6 @@ public class ResourceHttpRequestHandler extends WebContentGenerator
@ -1174,8 +1174,8 @@ the number of bytes are counted and the "Content-Length" header set.
@@ -1174,8 +1174,8 @@ the number of bytes are counted and the "Content-Length" header set.
HTTP OPTIONS request is handled by setting the "Allow" response header to the
HTTP methods explicitly declared on all `@RequestMapping` methods with matching
URL patterns. When no HTTP methods are explicitly declared the "Allow" header
is set to "GET,HEAD". Therefore it's highly recommended to always explicitly
declare the HTTP method(s) an `@RequestMapping` method is meant to handle.
is set to "GET,HEAD,POST,PUT,PATCH,DELETE,OPTIONS". Ideally always declare the
HTTP method(s) an `@RequestMapping` method is intended to handle.
Although not necessary an `@RequestMapping` method can be mapped to and handle