import type { IncomingMessage, ServerResponse } from 'node:http';
/** Hard cap on inbound JSON bodies for the Web REST API. */
export declare const MAX_API_BODY_BYTES: number;
/** Binary chat media (images/files) — keep in sync with WEB_MEDIA_MAX_BYTES. */
export declare const MAX_CHAT_MEDIA_BYTES: number;
export declare function readBody(req: IncomingMessage, res?: ServerResponse): Promise<string>;
export declare function readBinaryBody(req: IncomingMessage, res: ServerResponse, maxBytes: number): Promise<Buffer>;
export declare function sendJson(res: ServerResponse, status: number, data: unknown): void;
/**
 * Send a machine-readable error response. The SPA's `lib/api/client.ts`
 * reads `body.code` and maps it through `errors.json` → user-facing text;
 * the legacy `error` string remains as a fallback for tools that don't
 * speak the code dictionary (curl, older clients, tests grepping the
 * response).
 *
 * Convention: codes are UPPER_SNAKE, namespaced by feature when needed
 * (e.g. `EMAIL_NOT_CONFIGURED`, `MEMORY_USER_KEY_REQUIRED`). Bare names
 * like `VALIDATION` / `NOT_FOUND` cover broad buckets. Add new entries
 * to `src/web-app/src/i18n/locales/{en,zh}/errors.json` together with
 * the call site so the SPA picks up the human text.
 *
 * Use `detail` when the human message has variable parts the SPA can
 * interpolate (`{{detail}}` in the i18n template). Use `message` when
 * you want a fully-formed line that's safe to surface verbatim (the
 * SPA fallback path renders this when no per-code key exists).
 */
export declare function sendError(res: ServerResponse, status: number, code: string, options?: {
    message?: string;
    detail?: string;
    extra?: Record<string, unknown>;
}): void;
//# sourceMappingURL=http-utils.d.ts.map