Redirects and rewrites

Redirects and rewrites change how Easel handles a requested path.

Redirects

A redirect returns a 3xx response with a Location header. The browser or client then requests the destination URL.

Use redirects for:

Canonical hostnames
Moved pages
HTTP-to-HTTPS behavior
Legacy path migrations
Locale or product restructuring

Choose permanent status codes only when the change is intended to be durable and safe for clients and search engines to cache.

Rewrites

A rewrite changes the internal destination without changing the browser-visible URL.

Use rewrites for:

Mapping a public path to an internal application route
Serving a single-page application fallback
Proxying a supported external origin
Gradual application migrations

Framework configuration

Prefer the framework's documented redirect and rewrite configuration when Easel's framework integration consumes it.

Examples may include Next.js configuration, framework route rules, or generated deployment manifests.

Rule order

Rules are order-sensitive. Put specific rules before broad catch-all rules.

/account/settings  → /settings/profile
/account/*         → /new-account/*
/*                 → /index.html

Avoid loops

A rule loops when its output matches the same rule or another rule that returns to the original path. Test both source and destination forms, including trailing slashes and host normalization.

Caching

Redirect responses can be cached by browsers and shared caches depending on status and cache headers. Rewrites inherit the cache behavior of the final response.

Verification

Use a header-only request to inspect behavior:

curl -I https://example.com/old-path

For rewrites, inspect request details and logs to confirm the internal destination.