Cookies and network

This page pulls together the two places Rewind touches cookies and outbound networking: the per-request cookie jar toggle and the workspace-wide Global network settings.

The cookie jar

The cookie jar is a named, in-database collection of cookies. There is one default jar called default. It is created the first time a request runs with the jar enabled. The per-request toggle that turns the jar on and off lives on the Settings tab; this page is the deeper reference for what the jar does.

How it works

When a request has Use cookie jar turned on (in the Settings tab):

1. Before sending, Rewind looks up cookies in the jar whose domain and path match the request URL, and whose expiresAt is in the future. Those cookies are sent in a Cookie header.
2. After receiving the response, every Set-Cookie header is parsed and added to the jar. Existing cookies with the same (jarId, domain, path, name) are updated in place.

The jar is persistent: cookies survive a restart. To wipe it, click Clear cookies on the Settings tab, or call the cookies API.

What's in a cookie

Field	Meaning
name	Cookie name
value	Cookie value
domain	The domain the cookie applies to
path	URL path prefix; usually /
expiresAt	ISO timestamp; null means session cookie
secure	Send only over HTTPS
httpOnly	Not exposed to the browser (informational only here)
sameSite	Strict, Lax, None, or null

Things to know

• The jar is per workspace, not per request. Two requests against the same API share cookies.
• Cross-origin hops in a redirect chain drop the Authorization header but keep the cookie jar's matching cookies. These hops can surface as Browser origin is not allowed on the next request — see also Local session is not initialized if mutating requests start failing.
• The jar does not enforce cookie size limits; the browser does not see any of this traffic.
• HttpOnly is metadata only — Rewind never injects these into a browser context.

Global network

The Global network section is at the bottom of the Settings tab. It controls how every request is sent.

Proxy

• Proxy URL — an http:// or https:// proxy. If Proxy authorization is set, it is sent as a Proxy-Authorization header on every request that goes through the proxy.
• Setting an empty value clears the proxy. Saved network settings replace the old value in full — partial updates are not supported.

TLS

• Verify server TLS certificates — on by default. Turn this off if you point Rewind at a development server with a self-signed certificate.
• Custom CA — upload a PEM file. The file is stored as an attachment and used to verify server certificates in addition to the system trust store.
• Client certificate and Client key — upload PEM files for mutual TLS. Both must be present for mTLS to work; the client key without the certificate is ignored.

Uploaded files survive restarts and exports. They are stored under the workspace's data directory and are included in .rewind archive exports, but they are excluded from normal workspace exports for safety.

Saving

Click Save network settings at the bottom of the section. A brief "Saved" message confirms the update and runs a garbage collection pass on attachments.

What this looks like together

A typical development setup against an internal API looks like:

1. Open the request's Settings tab.
2. Turn on Use cookie jar if the API uses session cookies.
3. Scroll to Global network.
4. Paste the corporate proxy URL into Proxy URL.
5. Paste Basic <base64(user:pass)> into Proxy authorization.
6. Upload the corporate CA as Custom CA.
7. Click Save network settings.

The next request will go through the proxy and trust the internal CA without further configuration.

What's next?

• Request settings — the rest of the per-request options
• Troubleshooting — TLS and proxy errors that show up here