How is a HTTP request decoded in spring?

Question

So my question is something that I feel isn't addressed as much, My question is simple, How is a HTTP message(request) decoded or handled when it is received by the server(assuming the server is running a spring mvc application)?

To put my question into context, lets say a simple HTTP message is sent to a server by a client, where is the HTTP message decoded? In the sense that at some point some logic or code has to parse the HTTP request to see what it contains, my question is where does this action take place? Is it something that the dispatcher servlet is responsible for? is the application container ie tomcat responsible for parsing/decoding the HTTP message? If spring is responsible for it, please give what classes are involved in decoding the HTTP message.

Answer 1

It seems like Dispatcher servlet is responsible for decoding of HTTP requests, specifically HttpServlet . According to this source (and a few others), it seems that Dispatcher Servlet has a bunch of sublayers:

HttpServlet class is, as the name suggests, the HTTP-focused Servlet implementation, also defined by the specification.

In more practical terms, HttpServlet is an abstract class with a service() method implementation that splits the requests by the HTTP method type.

More on DispatcherServlet:

What we really want to do as developers of a web application is to abstract away the following tedious and boilerplate tasks and focus on useful business logic:

• mapping an HTTP request to a certain processing method
• parsing of HTTP request data and headers into data transfer objects (DTOs) or domain objects
• model-view-controller interaction
• generation of responses from DTOs, domain objects, etc.

The Spring DispatcherServlet provides exactly that.

PS: Great question! I have been using Spring for a while, but never really questioned the flow in such detail. Thanks for sending me down this path :)

Answer 2

Spring Web MVC runs inside a servlet container, like Tomcat .

Even when using Spring Boot, where you don't have to explicitly deploy a WAR file to a Tomcat instance installed on your machine, there is an instance of Tomcat (or another servlet container like Jetty, or Undertow - well not exactly servlet containers, but fulfilling the same role) running embedded inside your Spring Boot app.

The role of the servlet container is to implement the Servlet Specification from JEE (now Jakarta EE). So it is the servlet container that is responsible to listen to the HTTP port(s) (80, 8080, 443...), parse the HTTP requests it receives, and expose them to the upper layers via the Servlet API.

Similarly, the Servlet API allows to send the response to the client. It converts the Java objects and methods calls we pass to it to a correct HTTP response and sends it over the wire.

The servlet API is relatively low-level and to use it directly is quite verbose and tedious. That is why MVC frameworks such as Spring MVC (and before that Struts, and many others) and also JSF were built on top of it.

(Note that not all Java web frameworks are built on top of the Servlet API. One such example is the Play! framework.)

So, in turn, Spring MVC uses the Servlet API and builds upon it, and mostly hides it, in order to expose to you, the application programmer, its own API and offer you much more convenience and features, like

• dispatching the requests to your controllers based on the URL of the requests
• extracting and parsing JSON from the request body and exposing it to you as Java objects
• helping with file uploads
• and so on...

Now, if you use reactive endpoints ( Spring Web Reactive Framework ), it's a little different , and the Servlet API might not be directly involved. But that's another story.