Spring Framework resource handling is meant for serving static resources and providing infrastructure around that, like HTTP caching or serving resources from various locations.
Allowing POST methods on static resources would be in my opinion really surprising to most Spring developers. What is it supposed to do? In HTTP terms, POST is supposed to change the underlying resources, and here we're not talking about replacing the resource by something provided by the client.
You're suggesting that a POST, by default, does nothing to the resource and acts as a GET.
If we take a step back, it seems that the actual need is to map a POST request to something that you'd normally serve as a GET. In your particular case, you're serving your HTML view as a static resource, and probably rendering the UI on the client side. This is actually more a product of a constraint of your authentication system and the way you chose to handle views in your application. Other developers might choose another authentication system or render views with a templating engine.
Again, in your case, I believe you'd be in a much better place if you used actual controllers (and a templating engine) to show that view. In that case, you'd be in control of allowed HTTP methods on specific endpoints. If you're looking for an application-wide solution, then maybe a Servlet filter updating/forwarding the requests for those authentication cases would work best.
I'm closing this issue as I don't believe we'll implement this solution but rather focus on the issue.