HTTP Kernel and Bootstrap Process¶
SiteSupra does not use HttpKernel.
We had eight versions of SiteSupra before moving to Symfony. Unfortuantely, no all of the Symfony concepts do suit our needs well.
Our implementation is still a bit incomplete, especially
RequestStack and forwarding, so expect refactoring soon.
SiteSupra mimics Symfony behaviour as close as possible - a
Request object is created, every controller returns
Response (read more on controllers here).
Basically, request processing happens in the following order:
Web server hits entry point
SiteSupra builds container,
boot()is called. Two events are fired at that moment -
boot()is called for every registered package, allowing early initialization;
Request handling starts by calling
handleRequest($request). This method loads
handle(). Request handling by HttpKernel traverses through stages below:
KernelEvent::REQUESTis thrown. Request processing stops when there is at least one event configured for response to
RequestResponseEvent. Request object is returned;
- Kernel tries to resolve controller and action by checking
_actionparameters of request
AttributeBag; if found, controller is instantiated, action is called and
Controllerto return a
Response. This is used when forwarding requests or instantiating requests without a route;
- If controller is not resolved yet kernel loads routing and tries to find current route.
AttributeBagis overwritten by one created from route configuration and controller is actually executed.
KernelEvent::CONTROLLER_ENDevents are fired, and any listener can override response during
KernelEvent::CONTROLLER_ENDevent. If any exception (generic or
ResourceNotFoundException) is thrown request processing moves to exceptions processing (see stage 5 below);
- Kernel fires final
KernelEvent::RESPONSEevent and returns resulting
Responseobject. Exception is thrown when the object is not an instance of
- If any exception is caught during request processing, then the exception is processed in the following way:
- Kernel fires
KernelEvent::EXCEPTIONevent (again, if any listener provides
Responseinside this exception event, then the response is returned);
- If exception is instance of
ResourceNotFoundException, a special event is fired -
KernelEvent::ERROR404, which allows, for example, on-the-fly compilation of assets. Finally, if no response is available after the event is processed, the exception is re-thrown (in debug mode) or
exception404Actionof default exception controller (stored in container under
exception.controllerkey) is called;
- If there’s still and exception and no response, an exception is re-thrown (in debug mode) or
exception500Actionof default exception controller (stored in container under
exception.controllerkey) is called.
Resulting response is sent to the browser (by calling
send()method)). Any unhandled exception is caught by Debug component;
SiteSupra shuts down firing
Supra::EVENT_SHUTDOWN_ENDevents and calls
shutdown()method of all registered packages, thus allowing some late cleanup.
As you can see, this process is pretty simple and transparent. Last thing to note must be a
that is used throughout CMS backend for passing messages, warnings, and errors to frontend in a common way.
See the class source code to learn more on messaging process.