Function handle_request 

pub async fn handle_request<C: ConfigProvider>(
    req: Request<Incoming>,
    forward_host: Arc<str>,
    forward_port: u16,
    limiter: RateLimiter,
    config: Arc<C>,
    http_client: Client,
) -> Result<Response<Full<Bytes>>, Infallible>

Handles an incoming HTTP request through the proxy pipeline.

This is the main entry point for request processing. It performs:

• Client IP extraction and validation from proxy headers
• IP blocking checks
• URL pattern blocking (e.g., .php, .env files)
• HTTP method blocking (e.g., PUT, DELETE)
• Rate limiting per client IP
• Request forwarding to the upstream service

Arguments

• req - The incoming HTTP request
• forward_host - The upstream host to forward requests to
• forward_port - The upstream port to forward requests to
• limiter - The shared rate limiter instance
• config - Configuration provider for all settings
• http_client - HTTP client for forwarding requests (with connection pooling)

Returns

Always returns Ok with either:

• A successful proxied response from upstream
• An error response (403, 404, 405, 429, 502, etc.)

Runtime

This is an async function backed by reqwest/tokio; it must be awaited from inside a Tokio runtime (#[tokio::main], Runtime::block_on, etc.).

Security

• Strict mode (proxy allowlist configured): both X-Forwarded-For and Forwarded headers must be present. The proxy IP is taken from the Forwarded header’s by= field and matched against the allowlist; the client IP is taken from the last entry of X-Forwarded-For. Requests missing either header, or whose proxy is not in the allowlist, are rejected with 400 Bad Request.
• Permissive mode (no allowlist): if a request supplies an X-Forwarded-For or Forwarded header, the parsed IP is trusted as the real client IP and re-emitted to the upstream as X-Real-IP. An attacker can spoof this value by sending fake headers — only enable permissive mode when the proxy sits behind another layer that strips or normalises these headers.
• Any client-supplied X-Real-IP header is stripped before processing.
• The Authorization header is stripped before forwarding whenever wisegate performed authentication (see crate::AuthenticationProvider::forward_authorization_header).