/**
 * The bounds on the request bodies the resource-level routes will buffer:
 * /d1/create, /d1/query and /r2/create (Task 1702).
 *
 * Parallel to object-limits.ts, which bounds the object routes. Kept separate
 * because the facts differ: an object envelope is dominated by R2's 1,024-byte
 * object key limit, and these routes carry no key at all. Coupling them would tie
 * a D1 database name to R2's key limit, so a revision to either would move a bound
 * that has no reason to move.
 *
 * These are bounds on house memory. They do not adjudicate the last byte of a name
 * or a statement — the same stance object-limits.ts takes, for the same reason. The
 * house process holds the account-wide credential, so an out-of-memory kill there
 * takes the brand server down, and on the target hardware that is a hard freeze
 * that emits nothing.
 *
 * Deliberately dependency-free, like object-limits.ts: the ui route reads these
 * through the barrel, and nothing here needs the rest of the lib.
 */
/**
 * Cloudflare's documented maximum SQL statement length.
 *
 * "Maximum SQL statement length | 100,000 bytes (100 KB)"
 * https://developers.cloudflare.com/d1/platform/limits/
 *
 * Recorded because it is what governs a legitimate `sql`, and because
 * D1_QUERY_MAX_BODY_BYTES below is only knowable as safe by way of it.
 *
 * A second, independent bound applies to the same string on the way out, and is
 * recorded here so nobody rediscovers it as a bug: cf-exec's d1Query shells
 * `execFile("npx", ["wrangler", "d1", "execute", ..., "--command", sql])`, so the
 * decoded statement travels as a single argv element. Linux caps one such element
 * at MAX_ARG_STRLEN = 131,072 bytes and fails execve with E2BIG above it
 * (https://man7.org/linux/man-pages/man2/execve.2.html). That is a property of the
 * spawn path, not of D1. It does not bind first: 100,000 < 131,072, so a statement
 * D1 would accept always fits the spawn.
 */
export declare const D1_MAX_SQL_STATEMENT_BYTES = 100000;
/**
 * The worst-case expansion of a byte when it is serialized into a JSON string.
 *
 * A single ASCII control byte becomes the six characters \uXXXX. Multi-byte
 * characters are cheaper per byte — a 3-byte UTF-8 character also becomes six
 * characters (2x), and a non-BMP character becomes a 12-character surrogate pair
 * for 4 bytes (3x) — so 6 is a true ceiling over bytes, reached by ASCII.
 *
 * This is why a body limit is not simply the statement limit: the cap bounds the
 * wire body, and escaping moves the two apart.
 */
export declare const JSON_STRING_WORST_CASE_EXPANSION = 6;
/**
 * The largest JSON body /d1/create or /r2/create can legitimately carry: a single
 * resource name and JSON punctuation. No payload term, and no key term.
 *
 * Sized on headroom rather than a tight derivation, because only one of the two
 * names it bounds has a documented hard limit:
 *
 * - R2 bucket name: 3-63 characters, lowercase letters, digits and hyphens.
 *   https://developers.cloudflare.com/r2/buckets/create-buckets/
 * - D1 database name: no documented limit. The API reference states only
 *   `name: string`, "D1 database name" — no maxLength, pattern or charset.
 *   https://developers.cloudflare.com/api/resources/d1/subresources/database/
 *   The get-started guide gives guidance, not a limit: names "should use a
 *   combination of ASCII characters, shorter than 32 characters".
 *
 * So a real body is under ~100 bytes and 64 KiB clears it by roughly 650x, while
 * sitting ~2,100x below put's body limit: far above anything a real caller sends,
 * far below anything that threatens house memory. Nothing here depends on either
 * figure being exact. An undocumented D1 name limit cannot plausibly approach 64
 * KiB, and a request body is the wrong place to discover that it had.
 *
 * Deliberately not R2_OBJECT_ENVELOPE_MAX_BODY_BYTES, which happens to hold the
 * same value. That constant is governed by R2's object key limit; this one is not,
 * and the two must be free to drift. Couple what is one fact; separate what merely
 * matches today.
 */
export declare const STORAGE_RESOURCE_NAME_MAX_BODY_BYTES: number;
/**
 * The largest JSON body /d1/query can legitimately carry: a database name and a
 * SQL statement.
 *
 * The envelope reasoning behind the object routes' bound does not govern this. A
 * large but entirely legal migration or batch statement is not a 1,024-byte object
 * key, so applying that constant here would reject correct queries.
 *
 * The bound is on the wire body, not the decoded statement, and JSON escaping moves
 * those apart. The largest legal statement (D1_MAX_SQL_STATEMENT_BYTES) can present
 * a wire body of up to
 *
 *   JSON_STRING_WORST_CASE_EXPANSION * 100,000 + 65,536 = 665,536 bytes
 *
 * so capping at 100,000 would 413 a statement D1 would have accepted. 1 MiB clears
 * the worst case by about 1.6x and sits ~133x below put's body limit.
 *
 * It is a flat number rather than that expression, for legibility at the call site.
 * The arithmetic is not decoration: it is the only thing that makes 1 MiB knowable
 * as safe, so resource-limits.test.ts asserts the relationship. If D1 ever raises
 * its statement limit above 163,840 bytes, that test fails rather than this route
 * quietly beginning to refuse legal SQL.
 */
export declare const D1_QUERY_MAX_BODY_BYTES: number;
//# sourceMappingURL=resource-limits.d.ts.map