document early_request_filter

Fix #363
---
updated

Includes-commit: 204ddb0274
Includes-commit: 34c67f0aca
Replicated-from: https://github.com/cloudflare/pingora/pull/368
Signed-off-by: spacewander <spacewanderlzx@gmail.com>
This commit is contained in:
spacewander 2024-09-02 13:57:21 +00:00 committed by Gustav Davidsson
parent 2a4e152e80
commit 6c8e7aab73
4 changed files with 12 additions and 7 deletions

2
.bleep
View file

@ -1 +1 @@
265d5245705c6f762c7dd37536f9d1c61d2d8af9
6923a7f31ed6fff1ddaf00ffb8dd56311042c395

View file

@ -16,7 +16,8 @@ The pingora-proxy HTTP proxy framework supports highly programmable proxy behavi
Pingora-proxy allows users to insert arbitrary logic into the life of a request.
```mermaid
graph TD;
start("new request")-->request_filter;
start("new request")-->early_request_filter;
early_request_filter-->request_filter;
request_filter-->upstream_peer;
upstream_peer-->Connect{{IO: connect to upstream}};
@ -52,9 +53,12 @@ Pingora-proxy allows users to insert arbitrary logic into the life of a request.
* The reason both `upstream_response_*_filter()` and `response_*_filter()` exist is for HTTP caching integration reasons (still WIP).
### `request_filter()`
### `early_request_filter()`
This is the first phase of every request.
This function is similar to `request_filter()` but executes before any other logic, including downstream module logic. The main purpose of this function is to provide finer-grained control of the behavior of the modules.
### `request_filter()`
This phase is usually for validating request inputs, rate limiting, and initializing context.
### `proxy_upstream_filter()`

View file

@ -1,7 +1,8 @@
Pingora proxy phases without caching
```mermaid
graph TD;
start("new request")-->request_filter;
start("new request")-->early_request_filter;
early_request_filter-->request_filter;
request_filter-->upstream_peer;
upstream_peer-->Connect{{IO: connect to upstream}};

View file

@ -69,9 +69,9 @@ pub trait ProxyHttp {
/// Handle the incoming request before any downstream module is executed.
///
/// This function is similar to [Self::request_filter()] but execute before any other logic
/// especially the downstream modules. The main purpose of this function is to provide finer
/// grained control of behavior of the modules.
/// This function is similar to [Self::request_filter()] but executes before any other logic,
/// including downstream module logic. The main purpose of this function is to provide finer
/// grained control of the behavior of the modules.
///
/// Note that because this function is executed before any module that might provide access
/// control or rate limiting, logic should stay in request_filter() if it can in order to be