Laravel request lifecycle: from URL to response

Who this is for: PHP developers beginning with Laravel. You should be familiar with HTTP requests, PHP files, and the idea of a URL route.

What you will learn: how a request enters Laravel, how its route selects a controller action, how that action returns a view, and how the resulting response goes back to the browser.

Tested environment: TeachyLeaf's Laravel Framework 13.16.1 application running on PHP 8.3.30. The route and page walkthrough use this repository's current code. Laravel internals may change between framework versions.

Follow a real request

Open GET /about. In this application, that request moves through these main steps:

1. The web server sends the request to public/index.php, the application's HTTP entry point.
2. The front controller loads Composer's autoloader, bootstraps the application, captures the HTTP request, and asks Laravel to handle it.
3. The configured web middleware and router process the request. The router matches the HTTP method and URL to a registered route.
4. The route calls the about action on PageController.
5. The controller returns the frontend.about Blade view.
6. The view extends the shared frontend layout, which renders the page content between the shared header and footer.
7. Laravel returns the resulting HTTP response through the middleware stack and sends it to the browser.

This is a simplified path through a normal successful page request. Exceptions, redirects, sessions, authentication, and other middleware can change what happens or the response the browser receives.

1. The front controller receives the request

The real entry point is public/index.php. In this project it loads Composer's autoloader, loads the application configuration, captures the incoming request, and passes it to Laravel:

require __DIR__.'/../vendor/autoload.php';

$app = require_once __DIR__.'/../bootstrap/app.php';

$app->handleRequest(Request::capture());

You normally do not edit this file to add a page. It provides the entry point; application routes and controllers define the page behavior.

2. The application loads route configuration

bootstrap/app.php configures this application's route files and middleware options. The relevant route configuration points Laravel to routes/web.php:

->withRouting(
    web: __DIR__.'/../routes/web.php',
    commands: __DIR__.'/../routes/console.php',
    health: '/up',
)

Routes registered from web.php use the web middleware group. Middleware can inspect, allow, reject, or modify a request and its response. You can inspect a route's assigned middleware with Artisan rather than guessing:

php artisan route:list --path=about -vv

3. The router matches the request

The route definition connects the GET /about request to a named controller action:

Route::get('/about', [PageController::class, 'about'])
    ->name('about');

The HTTP method matters: this declaration handles a GET request. The route name, about, is also used to generate links with Laravel's route('about') helper, so a link does not need to hard-code the URL.

4. The controller chooses a view

The matched action in PageController returns a view:

public function about()
{
    return view('frontend.about');
}

The view name maps to resources/views/frontend/about.blade.php. A controller can also prepare data and pass it to the view; this action needs no extra data.

5. Blade renders the shared layout

The About page extends layouts.frontend and supplies its page content. The shared layout renders the navigation, inserts the page content, and then renders the footer:

@extends('layouts.frontend')

@section('content')
    <section class="content-hub-hero">
        ...
    </section>
@endsection

Blade turns the template into HTML. Laravel wraps that rendered output in an HTTP response. In this application, a successful GET of /about returns status 200 and an HTML page.

Trace it yourself

1. Run php artisan route:list --path=about -vv and find the route action and middleware.
2. Open routes/web.php and follow the route to PageController::about.
3. Follow the returned view name to its Blade file and inspect the layout it extends.
4. Request /about in a browser and compare the rendered page with the route and view you traced.

For another example, the contact form has a separate POST route and additional rate-limiting middleware. Follow that path only in a local test environment; submitting it can cause server-side form handling and should not be used as a harmless read-only example.

Key idea

A Laravel page request is not handled by one file alone: the front controller boots the application, middleware and routing process the request, a controller returns a response or view, and the rendered response is sent back to the browser. Trace those connections in the route list and source code when debugging a page.

Further reading

This explanation is grounded in the Laravel 13 request lifecycle documentation and Laravel 13 routing documentation. See the TeachyLeaf editorial approach for how examples are checked and updated.