HTTP OPTIONS response for @RequestMapping should contain OPTIONS consistently [SPR-16513]

[spring-projects-issues]

Graham Cox opened SPR-16513 and commented

I'll preface this by saying I'm not 100% sure this is really a bug. I can't find anything definitive in the HTTP RFCs as to whether an OPTIONS response should include itself as valid, however is seems unintuitive to not be consistent.

If a controller method doesn't specify it handles any specific HTTP methods, the OPTIONS response includes every possible HTTP method.

If the controller methods do specify that they handle specific HTTP methods, the OPTIONS response only includes these.

This means it's possible to make an OPTIONS request and get a successful response that claims that OPTIONS is not a valid method.

---

Affects: 5.0.3

Issue Links:

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

Referenced from: commits 6cf6d88

[spring-projects-issues]

Juergen Hoeller commented

This looks like an oversight indeed since Spring's ResourceHttpRequestHandler and WebContentGenerator explicitly always add OPTIONS to the declared methods... but RequestMappingInfoHandlerMapping doesn't. I've locally patched this and it seems to work fine through simply always adding OPTIONS in RequestMappingInfoHandlerMapping.HttpOptionsHandler as well.

Rossen Stoyanchev, Arjen Poutsma, Brian Clozel, Sébastien Deleuze, any insight here? Any strong opinions pro/contra always including OPTIONS for automatically generated OPTIONS responses on our end? Based on my own understanding and some quick research, I lean towards always including it: If we do this, we should do it for 5.0.4 right away and possibly backport it to 4.3.15 (since this automatic support for OPTIONS was a new 4.3 feature: #17721).

[spring-projects-issues]

Brian Clozel commented

I don't have anything against adding that, as it improves consistency.
If anything, it's redundant information; if the endpoint didn't support OPTIONS, then it would have replied "405 Method Not Allowed" in the first place.
I'm not sure this qualifies as Major as this missing value should have zero impact on clients.

[spring-projects-issues]

Graham Cox commented

I couldn't work out from RFCs whether it should be included or not in the response. However, I do think that it should be consistent regardless of how the @RequestMapping annotations are set up, which it isn't right now.

[spring-projects-issues]

Juergen Hoeller commented

After some further consideration, there are general differences between the mapping-derived OPTIONS response and the resource-derived OPTIONS response, so I'm not sure my consistency argument at that level is very strong.

That said, consistency within the mapping-derived OPTIONS responses is certainly to be revisited, aligned with common industry practices. Let's revisit that topic for 5.1 then.