HTTP requests

An HTTP request in Tetiva is a method, an address, headers and a body. The URL string is the source of truth: query parameters are parsed out of it into the Params tab and written back into it whenever you edit the table. Cookies are kept separately from the request — in a per-workspace store that survives an app restart.

Method and address#

Pick the method to the left of the address field: GET, POST, PUT, PATCH, DELETE, OPTIONS, HEAD. Method colors follow the Swagger UI convention, and the same color is repeated on the request badge in the sidebar.

There are two ways to fire the request: press Enter inside the URL field, or Cmd/Ctrl+Enter anywhere in the tab. Cmd/Ctrl+S saves it; unsaved edits are marked with a dot next to the tab strip.

Environment variables are resolved in the address. Type {{base_url}}/v1/users and {{base_url}} is replaced right before the call — see environments and variables.

Query parameters#

The Params tab reflects the query string of the current address. The link goes both ways: append ?page=2 to the URL and a row shows up in the table; edit a cell, add or delete a row and the address is rebuilt. Clearing a row's checkbox drops that parameter from the address without removing the row from the table.

Parameters have no storage of their own — the request stores the URL. A disabled row therefore lives as long as the tab is open; reopen the request and the table is rebuilt from the address.

Values typed into the table are URL-encoded, so a variable inside the query is better written directly in the address field: edit the row in the table and {{token}} becomes %7B%7Btoken%7D%7D, which no longer resolves.

Headers#

The Headers tab holds key-value pairs, each with its own checkbox. That checkbox is stored with the request: a disabled header is not sent and does not appear in Copy as cURL. It is a convenient way to keep two Authorization values side by side and switch between them without deleting either.

Tetiva fills in Content-Type from the body type — application/json for JSON, application/xml for XML, application/x-www-form-urlencoded for a form, application/octet-stream for a binary file. A header you typed yourself is never overwritten, with one exception: a form with file fields is always sent as multipart/form-data, and Tetiva sets that header itself so the boundary matches the encoded body. See request body.

Auth lives on its own tab and turns into a header or a query parameter at send time — see authentication.

Cookies#

Tetiva keeps its own cookie store in SQLite, isolated per workspace. Set-Cookie headers from responses are persisted and attached to later requests to the same domain, so the usual "log in once, then run the rest of the collection" flow needs no copy-paste.

The Cookies tab of a response has two sections: Sent — what the client attached to this request — and Received — what arrived in Set-Cookie, with every attribute. The "Manage cookies →" link opens the manager: domains on the left, the cookie table on the right. You can add a cookie by hand, edit it, delete a single row, clear one domain, or wipe the workspace store.

The cookie manager in Tetiva: domains on the left, the cookie table on the right — The workspace cookie jar: domains on the left, every attribute of a record on the right

Semantics follow RFC 6265, with one deliberate simplification:

a cookie sent without a Domain= attribute is host-only and matches the exact host; with Domain= it matches the host and its subdomains. Manually added cookies behave like the second case;
Set-Cookie with Max-Age=0 or an expiry in the past deletes the stored row, so a server-side logout really does clear the session;
a cookie with no explicit Path= gets Path=/; RFC 6265 asks for the directory default path, and this is a known simplification;
a cookie with no Expires and no Max-Age is a session cookie — the manager shows session in its Expires column, the same way browser DevTools do. Expired cookies are filtered out on read, session cookies are kept until you clear them.

What happens on send#

The client waits 30 seconds for a response and follows up to 10 consecutive redirects, attaching cookies at every hop. The result opens in the Body, Headers, Cookies and Tests tabs — reading a response is covered in response viewer, and the Tests tab is filled by scripts.