= = review = =
Let's review it again. public/index.php The code is as follows (excluding the detailed comments section).
<?php // public/index.php /** * Laravel - A PHP Framework For Web Artisans * * @package Laravel * @author Taylor Otwell <taylor@laravel.com> */ /* |-------------------------------------------------------------------------- | Register The Auto Loader Registered Class Autoloading |-------------------------------------------------------------------------- | */ require __DIR__.'/../bootstrap/autoload.php'; /* |-------------------------------------------------------------------------- | Turn On The Lights Turn on the light and light up (create a $app instance) |-------------------------------------------------------------------------- | */ $app = require_once __DIR__.'/../bootstrap/app.php'; /* |-------------------------------------------------------------------------- | Run The Application Let Applications Run |-------------------------------------------------------------------------- | */ $kernel = $app->make(Illuminate\Contracts\Http\Kernel::class); // Blog notes // $kernel = $app->make(App\Http\Kernel::class); // dump($kernel); $response = $kernel->handle( $request = Illuminate\Http\Request::capture() ); $response->send(); $kernel->terminate($request, $response);
In the previous section, bootstrap/autoload.php and bootstrap/app.php were analyzed in detail. Now look at the $kernel section, where the first line is puzzling, as follows:
$kernel = $app->make(Illuminate\Contracts\Http\Kernel::class);
What's not clear is that $kernel comes from the make() parsing method, that is, from the name of a class, which comes from the Kernel of Http (Web-oriented, not Console) in the protocol. Tests show that App Http Kernel is actually parsed. Beth, should be the result of single binding in bootstrap/app.php.
$app->singleton( Illuminate\Contracts\Http\Kernel::class, App\Http\Kernel::class );
This singleton() binds the Kernel in the protocol to App Http Kernel, and the Kernel in the make() protocol above appears, which is to parse App Http Kernel. The obvious advantage of this is that no matter which Kernel we bind to, make() can be achieved.
== Deep into App\ Http Kernel ==
Look at the location first, then enter the source code.
<?php namespace App\Http; use Illuminate\Foundation\Http\Kernel as HttpKernel; class Kernel extends HttpKernel { /** * The application's global HTTP middleware stack. * * These middleware are run during every request to your application. * * @var array */ protected $middleware = [ \Illuminate\Foundation\Http\Middleware\CheckForMaintenanceMode::class, \Illuminate\Foundation\Http\Middleware\ValidatePostSize::class, \App\Http\Middleware\TrimStrings::class, \Illuminate\Foundation\Http\Middleware\ConvertEmptyStringsToNull::class, ]; /** * The application's route middleware groups. * * @var array */ protected $middlewareGroups = [ 'web' => [ \App\Http\Middleware\EncryptCookies::class, \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class, \Illuminate\Session\Middleware\StartSession::class, // \Illuminate\Session\Middleware\AuthenticateSession::class, \Illuminate\View\Middleware\ShareErrorsFromSession::class, \App\Http\Middleware\VerifyCsrfToken::class, \Illuminate\Routing\Middleware\SubstituteBindings::class, ], 'api' => [ 'throttle:60,1', 'bindings', ], ]; /** * The application's route middleware. * * These middleware may be assigned to groups or used individually. * * @var array */ protected $routeMiddleware = [ 'auth' => \Illuminate\Auth\Middleware\Authenticate::class, 'auth.basic' => \Illuminate\Auth\Middleware\AuthenticateWithBasicAuth::class, 'bindings' => \Illuminate\Routing\Middleware\SubstituteBindings::class, 'can' => \Illuminate\Auth\Middleware\Authorize::class, 'guest' => \App\Http\Middleware\RedirectIfAuthenticated::class, 'throttle' => \Illuminate\Routing\Middleware\ThrottleRequests::class, ]; }
Seen from the source code, App Http Kernel inherits from the core base library Illuminate Foundation Http Kernel (appearing as the alias HttpKernel). The code of the core library Kernel is as follows:
<?php // laravel/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php namespace Illuminate\Foundation\Http; // use is omitted here. class Kernel implements KernelContract { /** * The application implementation. * * @var \Illuminate\Contracts\Foundation\Application */ protected $app; /** * The router instance. * * @var \Illuminate\Routing\Router */ protected $router; /** * The bootstrap classes for the application. * Bootstrapping classes, bootstrapping classes * There is basically a bootstrap(Application $app) method in these classes. * bootstrap applications from different perspectives. Prepare for the final boot(). * Note: These things can't be done, requests can't be accepted, or even $requests can't be generated correctly. * * @var array */ protected $bootstrappers = [ // Load the server environment variable (. env file?) \Illuminate\Foundation\Bootstrap\LoadEnvironmentVariables::class, // Load configuration information (config directory?) \Illuminate\Foundation\Bootstrap\LoadConfiguration::class, // Configuration how to handle exceptions \Illuminate\Foundation\Bootstrap\HandleExceptions::class, // Register Facades \Illuminate\Foundation\Bootstrap\RegisterFacades::class, // Register Providers \Illuminate\Foundation\Bootstrap\RegisterProviders::class, // Start Providers \Illuminate\Foundation\Bootstrap\BootProviders::class, ]; /** * The application's middleware stack. * * @var array */ protected $middleware = []; /** * The application's route middleware groups. * * @var array */ protected $middlewareGroups = []; /** * The application's route middleware. * * @var array */ protected $routeMiddleware = [];
Kernel also defines an important list of middleware. All request s must go through these middleware before they are processed by the application. After sifting through these middleware, they can be determined how to handle them. This involves the role of middleware. See the list of middleware defined in Kernel.php.
<?php // App\Http\Kernel.php namespace App\Http; use Illuminate\Foundation\Http\Kernel as HttpKernel; class Kernel extends HttpKernel { /** * The application's global HTTP middleware stack. * Applying global HTTP Middleware * * These middleware are run during every request to your application. * * @var array */ protected $middleware = [ // Check for maintenance mode \Illuminate\Foundation\Http\Middleware\CheckForMaintenanceMode::class, // Check the size of the Post request and report an exception too large \Illuminate\Foundation\Http\Middleware\ValidatePostSize::class, // In addition to the password, trim is required - to remove the blank characters (or other characters) at the beginning and end of the string. \App\Http\Middleware\TrimStrings::class, // Convert empty string ('') to null. \Illuminate\Foundation\Http\Middleware\ConvertEmptyStringsToNull::class, // These functions are similar to the common function of TP, but LA is subdivided in addition to calling them middleware. ]; /** * The application's route middleware groups. * Routing Middleware (Array) * * @var array */ protected $middlewareGroups = [ 'web' => [ // Encrypted Cookies: Encrypted or not, exception handling, etc., inherited from IlluminateCookie Middleware \App\Http\Middleware\EncryptCookies::class, // Add Cookies information to Response header. \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class, // Session Middleware \Illuminate\Session\Middleware\StartSession::class, // \Illuminate\Session\Middleware\AuthenticateSession::class, // View Middleware \Illuminate\View\Middleware\ShareErrorsFromSession::class, // To verify the forgery of cross-station requests, we should not stop at the level of csrf. These middleware are used to process requests. // Must find a way to deal with forged requests, La did it in the way of middleware. \App\Http\Middleware\VerifyCsrfToken::class, // Route Replacement Binding ~??? \Illuminate\Routing\Middleware\SubstituteBindings::class, // Each of the above classes has a handle($request, Closure $next), which is defined by itself. // The rule handles the routing and then returns $next ($request) to be secure or compliant. ], 'api' => [ 'throttle:60,1', 'bindings', ], ]; /** * The application's route middleware. * * These middleware may be assigned to groups or used individually. * * @var array */ protected $routeMiddleware = [ // Authenticate User Use 'auth' => \Illuminate\Auth\Middleware\Authenticate::class, // Basic Verification: By email and password? 'auth.basic' => \Illuminate\Auth\Middleware\AuthenticateWithBasicAuth::class, // replace? TP has replacement, the same? 'bindings' => \Illuminate\Routing\Middleware\SubstituteBindings::class, // User rights, this is more specific, the development of the use of 'can' => \Illuminate\Auth\Middleware\Authorize::class, 'guest' => \App\Http\Middleware\RedirectIfAuthenticated::class, 'throttle' => \Illuminate\Routing\Middleware\ThrottleRequests::class, ]; }
Is the $middleware [] above global, especially for HTTP, the lower level? The latter $middleware Groups [] and $routeMiddleware [] are more specific implementation levels. Should be able to continue to add according to development needs.
In short, Kernel did two things. The first one was to define $bootstraps [], to prepare the boot system, and the second one was to define various middleware, which processed, processed, selected and judged the $request, and ultimately prepared for a correct and effective $response. After that, Kernel did $kernel - > handle ($request) in index.php and returned $r. Esponse.
== Summary== Summary
$request ---> $kernel { middlewares/routers } ---> $response
Kernel is a big black box, sending requests and outputting responses. We just add middleware, routing and so on. _