Orientation Arc
Routing Algorithms
Rendering and JSX
Runtime Adapters
Middleware Ecosystem
Developer Helpers
System Utilities
The following files were used as context for generating this wiki page:
"HTTP Helpers" in Hono serve as a modular suite of utility functions designed to abstract the complexities of standard web interfaces into developer-friendly APIs. By wrapping common HTTP tasks—such as header manipulation, connection metadata extraction, and content-negotiation—into coherent helpers, they allow developers to interact with the request/response lifecycle without manual implementation of low-level specs.
The design philosophy prioritizes platform portability and architectural separation. Because Hono is built on Web Standards, these helpers are designed to be environment-agnostic where possible, while exposing specific "adapter" modules for platform-specific capabilities (like AWS Lambda, Cloudflare, or Deno). This separation ensures the core framework remains lean while allowing the community to implement deep integrations for specialized environments.
These helpers exist to solve the "plumbing" problems of web development: safely extracting proxy-aware client IP addresses, parsing complex Accept headers into ranked arrays, and simplifying cross-platform WebSocket upgrades. They act as the bridge between the raw Request/Response interface and the semantic requirements of a feature-rich web application, maintaining stability across divergent runtime behaviors.
ConnInfo)The ConnInfo subsystem provides a unified API for retrieving network metadata, specifically the remote client address. Because different platforms (e.g., AWS Lambda, Bun, Cloudflare) propagate client IP addresses through different headers (like cf-connecting-ip or x-forwarded-for), Hono exposes platform-specific implementations that normalize this access through the ConnInfo interface.
Tip
Use getConnInfo(c) to abstract away platform-specific header parsing; never manually parse x-forwarded-for if an adapter provides a getConnInfo implementation.
Sources: src/helper/conninfo/types.ts:1-46, src/adapter/aws-lambda/conninfo.ts:1-74
Accepts)The accepts helper provides a mechanism to parse standard Accept headers (e.g., Accept-Language, Accept) and match them against a server's supported values. The mechanism uses a recursive parser that consumes the header string, tracking quality factors (q) and parameter keys/values, ultimately returning the best match based on client preference.
The selection logic follows a descending sort by quality factor. In the defaultMatch implementation, candidates are sorted such that b.q - a.q ensures the client's most-preferred media type or language is selected.
Sources: src/utils/accept.ts:211-238, src/helper/accepts/accepts.ts:21-25
The upgradeWebSocket helper abstracts the platform-specific ceremony required to transition an HTTP connection to a WebSocket connection. It defines a WSContext that mirrors standard event listeners (onOpen, onMessage, onClose, onError), providing a platform-independent way to define logic.
For platform implementations (e.g., src/adapter/deno/websocket.ts), this helper performs the necessary native upgrade, creates the context, and binds the provided listener functions.
Sources: src/helper/websocket/index.ts:70-91, src/adapter/deno/websocket.ts:4-38
The secureHeaders helper is a complex middleware responsible for injecting security-focused headers into the response. It pre-processes security options (CSP, Permissions-Policy, etc.) into a normalized set of header pairs.
The mechanism uses a callback-based architecture to defer the finalization of headers until the request lifecycle has progressed. A key invariant is the Content-Security-Policy callback which handles dynamic values like nonce generation.
Important
The secureHeaders middleware evaluates callbacks before calling await next(). This ensures that nonce values set in the context are available for the entire response lifecycle.
Sources: src/middleware/secure-headers/secure-headers.ts:181-224
The proxy helper facilitates request forwarding by stripping "Hop-by-Hop" headers per RFC 2616 (e.g., Connection, Keep-Alive). This is crucial for avoiding header injection attacks and maintaining protocol integrity when acting as a gateway.
The implementation performs a strict check: if strictConnectionProcessing is enabled, it parses the Connection header and removes any listed headers, throwing an HTTPException if it encounters invalid characters that violate the token syntax.
Sources: src/helper/proxy/index.ts:10-19, src/helper/proxy/index.ts:60-78
The url.ts utilities provide logic for routing and query parameter parsing. A notable mechanism is _getQueryParam, which is optimized for both simple and complex (encoded) URLs. It avoids the overhead of URLSearchParams for trivial cases by manually searching the ? and & indices in the raw string.
// Example of manual index-based search used for optimization
while (keyIndex !== -1) {
const trailingKeyCode = url.charCodeAt(keyIndex + key.length + 1)
if (trailingKeyCode === 61) { // '='
// Extract slice...
}
}Sources: src/utils/url.ts:219-246