The Laravel Request Lifecycle: Route to Response

In a Laravel web application, the web server sends each HTTP request to Laravel. Laravel runs code that checks or changes the request. It then matches the request’s method and URL to a handler and runs that handler. The handler returns a value, which Laravel prepares as an HTTP response and sends to the client. The checking code can stop the request before the handler runs or change the response as Laravel sends it back.

A route connects an HTTP method and URL pattern to the code that handles a request. Middleware is code that checks or changes a request or response as Laravel handles it. Following these steps helps explain why a controller runs, why it does not run, and how Laravel prepares a response.

Laravel captures the request and prepares the application

The web server sends the request to Laravel’s front controller, the PHP entry point at public/index.php. In Laravel 13, that file loads Composer’s autoloader, gets the application from bootstrap/app.php, captures the incoming HTTP request, and passes it to $app->handleRequest(...) in the Laravel 13 application entry point.

The captured request represents the incoming HTTP message as a Laravel object. It carries details such as the method, URL, headers, and input for framework code and middleware to inspect. Before Laravel handles the request, setup code makes framework services available. Service providers register those services and run their setup code. Routing uses the services they prepare.

Laravel’s lifecycle overview describes the broader setup and handling sequence, but its HTTP-kernel handoff is version-sensitive. For Laravel 13, follow the skeleton’s handleRequest entry point rather than treating the overview’s kernel description as an exact call trace.

Global middleware runs before route handling

Laravel first passes the request through global middleware. Each middleware either passes the request to the next step or returns a response. For example, authentication middleware can redirect a request before Laravel reaches the route action. Middleware that passes the request onward can inspect or change the response after the code it called returns.

Each application configures its own middleware stack, so the global middleware and its order depend on that configuration. Laravel’s middleware documentation explains how applications organize middleware for all requests and for route groups such as web and api.

The router matches a route, then runs its middleware

The router compares the request with registered routes and chooses one that matches details such as the HTTP method and URL. Route constraints limit which URL patterns match, and a route can provide matched parts of the URL as parameters. In Laravel 13, the Router source shows how the router finds a route and associates it with the request; it also dispatches a route-matched event.

After matching a route, the router loads and runs the middleware assigned to that route or its group. The router selects route middleware based on the matched route, while global middleware runs around the full handling of the request. Route middleware can pass the request to the action, reject it, or return a response before the action runs.

Some route groups include SubstituteBindings, middleware that turns a route parameter into a value such as a model. When this middleware is in the route’s stack, the action receives that value. The application’s middleware configuration determines whether binding happens. If an action receives a raw identifier instead of a model, check the route group’s middleware.

The route action returns a value

Laravel runs the matched route’s action after the request passes its applicable middleware. The action can be a closure or a controller method. Laravel’s controller dispatcher handles dispatching a route to its controller and method.

The route action typically loads or changes data. It also applies business rules and chooses what to return. A matched route does not guarantee that a controller will run: middleware can return early, and some routes use closures instead of controllers.

Laravel prepares the response and sends it back

Laravel turns an action’s return value into an HTTP response. It uses a string as response content and converts an array to a JSON response. An action can also return a response object to set details such as the status code and headers. Laravel documents these conversions in its HTTP response documentation.

The response travels back through the route middleware that passed the request to the next step. That middleware can inspect or change the response before returning it to the entry point, which sends it to the client. The request moves toward the route action; the response moves back through the middleware and out to the client.

Web server
  → public/index.php captures the request
  → Laravel prepares the application and runs global middleware
  → Router matches a route
  → Route middleware runs
  → Closure or controller action returns a value
  → Laravel prepares an HTTP response
  ← Route middleware can inspect or modify the response
  ← Laravel sends the response

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com