Spring should have default support for OPTIONS, HEAD and Allow [SPR-13130]

[spring-projects-issues]

Michael Osipov opened SPR-13130 and commented

Consider this simple REST controller:

@RestController
@RequestMapping("/rest/projects")
public class ProjectsController {

  @RequestMapping(value = "/{project}",
      method = { RequestMethod.GET },
      produces = { MediaType.APPLICATION_XML_VALUE, "application/json;charset=UTF-8" })
  public ResponseEntity<Project> lookupProject(
      @PathVariable("project") String project,
      @RequestParam(value = "attributes", required = false) String[] attributes,
      @RequestParam(value = "outputType", defaultValue = "hash") OutputType outputType,
      @RequestParam(value = "omitEmptyResponse", defaultValue = "true") boolean omitEmptyResponse)
      throws MissingServletRequestParameterException {
    ...
  }

}

In my web.xml I have set dispatchOptionsRequest to true.

HEAD requests are not automatically served by the framework:

$ curl --verbose -I http://localhost:8081/app/rest/projects/123 -H "Accept: application/json"
*   Trying 147.54.67.187...
* Connected to localhost (...) port 8081 (#0)
> HEAD /app/rest/projects/123 HTTP/1.1
> Host: localhost:8081
> User-Agent: curl/7.42.1
> Accept: application/json
>
< HTTP/1.1 405 Method Not Allowed
HTTP/1.1 405 Method Not Allowed
< Server: Apache-Coyote/1.1
Server: Apache-Coyote/1.1
< Allow: GET
Allow: GET
< Content-Type: text/html;charset=utf-8
Content-Type: text/html;charset=utf-8
< Content-Length: 1105
Content-Length: 1105
< Date: Mon, 15 Jun 2015 13:59:16 GMT
Date: Mon, 15 Jun 2015 13:59:16 GMT

<
* Connection #0 to host localhost left intact

This means that all GET methods need to have RequestMethod.HEAD. The behavior of the framework violates the HTTP RFCs, as far as I can see.

OPTIONS request responds with 405 where I would expect a 200 OK.

$ curl --verbose -X OPTIONS http://localhost:8081/app/rest/projects/123 -H "Accept: application/json"
*   Trying 147.54.67.187...
* Connected to localhost () port 8081 (#0)
> OPTIONS /app/rest/projects/123 HTTP/1.1
> Host: localhost:8081
> User-Agent: curl/7.42.1
> Accept: application/json
>
< HTTP/1.1 405 Method Not Allowed
< Server: Apache-Coyote/1.1
< Allow: GET
< Content-Type: text/html;charset=utf-8
< Content-Length: 1108
< Date: Mon, 15 Jun 2015 14:01:57 GMT
<
* Connection #0 to host localhost left intact

One has to implement OPTIONS for every single request mapping. Very annoying. Moreover, the Allow header does neither include HEAD nor OPTIONS.

Not implemented methods respond with an incorrect Allow header:

i$ curl --verbose -X TRACE http://localhost:8081/app/rest/projects/123 -H "Accept: application/json"
*   Trying 147.54.67.187...
* Connected to localhost () port 8081 (#0)
> TRACE /app/rest/projects/123 HTTP/1.1
> Host: localhost:8081
> User-Agent: curl/7.42.1
> Accept: application/json
>
< HTTP/1.1 405 Method Not Allowed
< Server: Apache-Coyote/1.1
< Allow: POST, GET, DELETE, OPTIONS, PUT, HEAD
< Content-Length: 0
< Date: Mon, 15 Jun 2015 14:04:24 GMT
<
* Connection #0 to host localhost left intact

---

Affects: 4.1.6

Issue Links:

• Regression: Handler method detection reporting ambiguous methods for explicit HEAD mapping [SPR-14182] #18753 Regression: Handler method detection reporting ambiguous methods for explicit HEAD mapping
• Support for HTTP Vary configuration (e.g. in reaction to locale-based rendering) [SPR-14070] #18642 Support for HTTP Vary configuration (e.g. in reaction to locale-based rendering)
• Support for conditional PUT in Web MVC (using If-Unmodified-Since header) [SPR-13863] #18436 Support for conditional PUT in Web MVC (using If-Unmodified-Since header)
• Mis-typed URL should give 404 not 405 [SPR-13944] #18516 Mis-typed URL should give 404 not 405
• HTTP OPTIONS response for @RequestMapping should contain OPTIONS consistently [SPR-16513] #21056 HTTP OPTIONS response for @RequestMapping should contain OPTIONS consistently

1 votes, 8 watchers

[spring-projects-issues]

Adam commented

I just got a report from a "security scanning" of my web application based on Spring and this report states that OPTIONS working like this allow for probing the API for allowed methods on an endpoint which makes the like of an attacker easier. Moreover, it is not possible to block such attacker on a firewall (WAF) when he/she probes endpoints like this, since the response is correct (HTTP 200). So I guess my point is that this feature should be easily turned off in application.properties or something. I found the key:

spring.mvc.dispatch-options-request=false

is causing the responses being misleading by containing all HTTP methods in the response instead of the actual ones mapped in controllers.

[spring-projects-issues]

Rossen Stoyanchev commented

Please refrain from commenting on 2 year old tickets. Once a release is shipped, tickets are closed, and will never be re-opened. You need to create a new ticket. Keep in mind the advice from your security tools is far from clear and debatable at best. As for the option that you're pointing out that's in Spring Boot (a separate project) with its own issue tracker.