#Processing Flow

Service first converts the request into Salvo's Response, then proceeds to the route matching phase.

#Route Matching Phase

During route matching, filters are executed sequentially in the order they were added, from outer to inner and top to bottom. If any filter fails to execute, the match is considered unsuccessful.

During the matching process, the path information of the request is processed. As matching progresses, once a path filter successfully matches, it consumes the matched portion of the path. If all path segments are consumed and no filters in the matching chain fail, and the last Router in the current chain has a goal Handler, the match is successful, concluding the matching phase. All Handlers from the matching chain are collected and proceed to the execution phase.

If the path is not fully consumed, no errors occur in the filter chain, but there are no more sub-routes to continue matching, the current chain is considered a failed match, and the process moves to the next route matching attempt.

If all routes are matched without success, the process enters the error-catching phase.

#Handler Execution Phase

The collected Handlers from the matching phase are executed sequentially. During execution, preceding middleware can call ctrl::call_next() to allow subsequent middleware to execute first before running its own logic. If an error status code or redirection occurs during execution, subsequent Handlers will not be executed. If the status code indicates an error and the Response's Body is unset or is ResBody::Error, the process enters the error-catching phase; otherwise, it skips this phase.

#Error-Catching Phase

Catcher is a type designed to handle errors and can also include middleware (hoops). Errors pass through all Handlers within the Catcher sequentially. If a Handler has processed the error and wishes to skip subsequent Handlers, it can use ctrl.skip_rest() to bypass the remaining Handlers and directly conclude the error-catching phase.

A Catcher must include at least one Handler as the default error handler. The default is DefaultGoal, but you can fully customize your own Handler as the default error-handling implementation. It displays error messages in formats corresponding to the content-type requested in the headers, supporting json, xml, text, and html formats. DefaultGoal also provides display settings—for example, by default, when displaying in HTML format, it includes Salvo-related links. You can call DefaultGoal::footer or DefaultGoal::with_footer to customize the footer as desired.

Service converts Salvo's Response into Hyper's Response type, which is ultimately returned to clients such as browsers.

#Salvo Request Lifecycle

This is a visual representation and explanation of the HTTP request lifecycle in the Salvo web framework.