In some cases we'd like to use MockServerHttpRequest with methods not in Spring's HttpMethod enum (for testing corner cases for example).
My scenario was wanting to use MockServerHttpRequest with the CONNECT method, which isn't in HttpMethod.
When ServerHttpRequest receives a request from Reactor Netty it can accept CONNECT as a string method even though it's not in the enum.
I believe we should also add a string-based method initialization to MockServerHttpRequest.
This was originally described in #24820 but I was asked to create a separate issue for this. @rstoyanchev FYI
Comment From: sbrannen
As pointed out by @eleftherias, the change associated with this issue is actually a breaking change for anyone that previously supplied null for the HttpMethod.
For example, the following used to be supported but now throws an IllegalArgumentException.
MockServerHttpRequest.method(null, "/").build();
In light of that, perhaps we should reopen this issue to again support null for the HttpMethod.
@rstoyanchev Thoughts?
See also: https://github.com/spring-projects/spring-security/issues/8592
Comment From: rstoyanchev
My only concern is that Spring Security had no choice but to pass null since it was the only way to simulate a custom method. Aside from that there is no reason to pass null. My thought is to leave it the way it is but have a more helpful error message along the lines of "if you are passing null to simulate a custom method, please use ... instead". After all it's a test that's failing and it's easy to correct.
Comment From: sbrannen
My thought is to leave it the way it is but have a more helpful error message
Fair enough. Let's just hope there weren't many projects depending on the previous unintentional support for null.