Skip to main content

handle_request

wisegate_core::request_handler

Function handle_request 

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

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
  • peer_addr - Address of the TCP peer that sent the 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): the TCP peer must be in the allowlist (or be a loopback address when crate::ProxyProvider::trust_loopback_proxy is enabled). Only the last element of the Forwarded header, the one that proxy appended, is used: its by= must be in the allowlist and its for= is the client IP. X-Forwarded-For is ignored. Requests failing any of these checks 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).