/**
 * HTTP / CDN cache primitives — the server-side mirror of the
 * `actuateTags()` helper exposed by `@actuate-media/client`.
 *
 * These produce the canonical tag strings that:
 *
 * 1. The SDK emits on every GET it makes (see
 *    `packages/client/src/index.ts`), and
 * 2. The action layer fires through `CacheConfig.onInvalidate` after every
 *    write so a Next.js host app can call `revalidateTag()` for each one.
 *
 * The cms-core in-process cache adapter (`./index.ts`) is a separate
 * concern and uses its own key/tag taxonomy for in-process bookkeeping —
 * the two layers never share tag strings.
 */
import type { CacheConfig } from '../config/types.js';
/** A single canonical tag for `revalidateTag()`-style invalidation. */
export type ActuateTagKind = 'collection' | 'doc' | 'global' | 'path';
/** The wholesale tag added to every SDK request — panic-button invalidation. */
export declare const ACTUATE_TAG_ROOT = "actuate";
/**
 * Build a single canonical tag (e.g. `actuate:collection:posts`). Mirrors
 * the SDK's `actuateTag()` so the server can construct invalidation keys
 * that match what the client will actually invalidate.
 */
export declare function actuateTag(kind: ActuateTagKind, slug: string): string;
/**
 * Tag set to invalidate after a write. Always includes the wholesale
 * `actuate` tag plus the narrowest specific tags so consumers who only
 * tagged broadly (or only tagged narrowly) both pick up the change.
 *
 * - `create` / `update` / `delete` on a doc → collection + doc tags.
 * - `update` on a global → global tag.
 *
 * Paths (`actuate:path:<path>`) are intentionally NOT auto-invalidated
 * here: the server cannot know which paths resolve to which doc without
 * re-running the resolver, and a stale slug change is a rare-enough
 * event that the host app should handle it in its own webhook.
 */
export declare function invalidationTagsForDocumentWrite(collection: string, documentId: string): string[];
export declare function invalidationTagsForGlobalWrite(slug: string): string[];
/**
 * Build the `Cache-Control` header value for a public read response.
 *
 * Rules:
 *
 * - Session-cookie authentication ALWAYS returns `private, no-store`.
 *   Shared CDNs MUST NOT cache per-user responses, full stop.
 * - When `cache.publicReads.enabled` is false (the default), returns
 *   null — caller emits no `Cache-Control` header.
 * - When enabled and the request is unauthenticated or uses an API
 *   key, returns
 *   `public, s-maxage=<maxAge>, stale-while-revalidate=<swr>`.
 *
 * @param request The inbound request — used to detect session cookies.
 * @param cache   `ActuateCMSConfig.cache` (may be undefined).
 * @returns       The `Cache-Control` header value, or null when none should be sent.
 */
export declare function publicReadCacheControl(request: Request, cache: CacheConfig | undefined): string | null;
/**
 * Returns true when the request carries the Actuate session cookie. We
 * deliberately check the cookie NAME, not its validity — an expired or
 * tampered cookie is still associated with a single user agent, so
 * treating it as "potentially-authenticated" and refusing shared-cache
 * is the safe default.
 *
 * Exported so the runtime-cache layer can reuse the exact same bypass
 * rule as the CDN-cache layer.
 */
export declare function hasSessionCookie(request: Request): boolean;
/**
 * Build a stable, content-addressed cache key for a public read.
 *
 * - Path-only when the URL has no query (`/api/cms/collections/posts`).
 * - Path + sorted query when present, so `?page=2&pageSize=20` keys the
 *   same way regardless of param order.
 * - Hashing isn't done here — the runtime cache adapter is free to apply
 *   its own `keyHashFunction` if it cares about key length.
 *
 * Exported for tests + custom routes that want to opt into the same
 * cache layer.
 */
export declare function cacheKeyFor(request: Request): string;
/**
 * Run a read endpoint through the optional Runtime Cache layer.
 *
 * Contract:
 *   - When `cache.runtimeCache.adapter` is unset, OR the request carries
 *     a session cookie, OR the caller sent `Cache-Control: no-cache`,
 *     this helper just invokes `build()` and returns whatever it
 *     produces (either a `Response` for early-exit cases like 404, or
 *     plain JSON-able data that gets wrapped via `wrap()`).
 *   - On cache hit, the cached payload is returned via `wrap(hit, request)`
 *     so the same CDN-tier `Cache-Control` rules apply. Hits get
 *     `X-Actuate-Cache: HIT`; misses get `X-Actuate-Cache: MISS`.
 *   - On cache miss, `build()` runs. If it returns a `Response` (e.g.
 *     404), that response is passed through untouched — we never cache
 *     error / not-found shapes. Otherwise the payload is stored under
 *     the cache key with the supplied tags and TTL.
 *   - Adapter errors (`get` or `set` throwing) are logged and swallowed.
 *     The user-visible request never fails because the cache fell over.
 *   - Payloads larger than ~1.5 MB are not stored — keeps us comfortably
 *     under the 2 MB Vercel runtime-cache item ceiling.
 */
export declare function cachedRead(request: Request, opts: {
    /** Tag set associated with the cache entry. Must match the SDK + onInvalidate tags. */
    tags: string[];
    /**
     * Produces the payload on cache miss. May short-circuit by returning
     * a `Response` (e.g. when emitting a 404); that response is never
     * cached.
     */
    build: () => Promise<Response | unknown>;
    /** Wraps a plain payload into the final `Response`. Typically this calls `jsonWithCache`. */
    wrap: (payload: unknown, request: Request) => Response;
    /** Active CMS config. Passed in to keep this helper pure (no `globalThis`). */
    cache: CacheConfig | undefined;
}): Promise<Response>;
//# sourceMappingURL=http.d.ts.map