Inconsistent Content-Type Validation in RouterFunctionMapping

[AkashB23]

In applications that use RouterFunctions—for example, Spring Cloud Gateway MVC—a GET request with an invalid or wildcard Content-Type header (e.g., /) results in an: IllegalArgumentException

📍 This behavior originates from the following line in Spring Framework:
RouterFunctionMapping.java#L212

⚠️ Issue
Unlike traditional Spring MVC applications—where Content-Type is primarily validated for POST, PUT, and PATCH requests—this validation occurs even for GET requests in the RouterFunctionMapping (there is no method based validation the exception is part of converting the servletRequest to ServerRequest.

This leads to an inconsistent experience and unexpected failures.

[bclozel]

I would argue that rejecting invalid requests is not unexpected behavior. If anything, we could align the behavior on the annotation model to reject those invalid requests early.

Let's rather focus on the problem at hand. Do those GET requests actually have a request body? If not, removing the "Content-Type" request header in a WebFilter early would solve the problem and avoid many issues.

[AkashB23]

Hi @bclozel, yes, I agree that it's technically invalid to include a Content-Type header in a GET request.

However, my query is more about the behavioral difference between the two approaches:

In a traditional @Controller-based Spring MVC setup, the presence of a Content-Type header in a GET request is ignored.

In contrast, with RouterFunction, it results in an IllegalArgumentException, which feels inconsistent.

In cases where the request doesn't carry a body, the header can indeed be removed. But when using something like Spring Cloud Gateway MVC, the request is often forwarded to a black-box target service, and modifying headers blindly might not be ideal or even feasible.

Would it make sense to align this behavior with the traditional DispatcherServlet to avoid surprises in such proxy-style use cases?

[bclozel]

I don't think this will make things better overall:

• this does happen already for annotated controllers, when a "consumes" attribute is set on mapping annotations
• applications currently working with the annotation model will fail and developers will consider that a regression
• this will not solve your problem

The only inconsistency here is that the functional model always parses the content type header early because the routing model is different. We could perform even more checks on HTTP requests, but that wouldn't by us much and would make performance worse.

If Spring Cloud Gateway applications expect invalid requests like this, I think they should write a short HandlerFilterFunction that cleans up incoming requests.

In summary, I don't think the tradeoffs are in favor of making this change as it will disrupt existing apps and won't really help others.

Thanks for reaching out!