Request and protocol blocks
Every panel below is a local reference: it never contacts the URL or service shown in its trace. The Variables and Edge cases tabs reflect the current execution engine contract.
HTTP Request
The HTTP block supports the selectable RustTLS, WreqTLS, and AzureTLS client paths, response namespaces, redirect handling, cookies, and request-body modes.
Configuration Behavior Variables Edge cases
method, url, headers, body/body_type, content_type follow_redirects + max_redirects; timeout_ms; HTTP version response_var (default SOURCE); custom_cookies; basic_auth ssl_verify / proxy_insecure; TLS client and its profile or overrides Sends through RustTLS, WreqTLS, or AzureTLS and stores the completed response under response_var. Redirect behavior is controlled by follow_redirects / auto_redirect; response URL is the final URL. The transport-specific controls are meaningful only for their selected TLS client. GET https://api.example.test/profile
200 → data.SOURCE = {…}; data.SOURCE.STATUS = 200
Failure → data.SOURCE.ERROR is set and stale response variables are not retained. data.{response_var} — response bodydata.{response_var}.STATUS / .URLdata.{response_var}.HEADERS and .COOKIES, plus indexed keysCompatibility aliases: data.RESPONSECODE, data.ADDRESS, data.LASTRESPONSE, data.LASTHEADERS A failed request clears prior response state before downstream checks; inspect data.{response_var}.ERROR. proxy_insecure disables target verification too for RustTLS/WreqTLS because TLS config is client-scoped; AzureTLS handles proxy TLS separately. Multipart is rejected when its required field contract is missing; it is not silently sent as malformed raw data.
TCP Request
Use this for raw TCP application protocols where you own or are authorized to test the target service.
Configuration Behavior Variables Edge cases
host, port, data, timeout_ms use_tls and ssl_verify output_var (default TCP_RESPONSE) and capture Opens a TCP connection, writes data, and stores the received protocol text in output_var. TLS is optional; certificate verification follows ssl_verify. host:port + payload → socket response
TCP_RESPONSE = "…" {output_var} — received response textCAPTURE.{output_var} when capture is enabled Use an explicit timeout: a service may accept a socket but never send a banner. TLS settings are only applied when use_tls is enabled. A connection failure is a block error; it does not create a fabricated response.
UDP Request
Use this for one datagram request/response exchange; it does not add a protocol-specific framing layer.
Configuration Behavior Variables Edge cases
host, port, datagram data, timeout_ms output_var (default UDP_RESPONSE) and capture Sends one UDP datagram and stores the received datagram text in output_var. datagram → UDP response
UDP_RESPONSE = "…" {output_var} — received datagram textCAPTURE.{output_var} when capture is enabled UDP is connectionless: no response before timeout is not evidence that the destination is unreachable. Use the correct service port and payload framing; the block does not invent protocol framing.
FTP Request
FTP transfer actions are path-sensitive. Review the edge cases before enabling RETR or STOR in an automated pipeline.
Configuration Behavior Variables Edge cases
host, port, username, password, timeout_ms command: LIST / RETR / STOR / DELE / MKD / RMD / CWD remote_path; local_path for STOR; output_dir for RETR output_var (default FTP_RESPONSE) and capture Authenticates to the configured FTP service and records a control-channel transcript in output_var. The current executor has no data-channel implementation: RETR/STOR do not transfer files. LIST /remote → FTP_RESPONSE transcript
RETR /remote/file → command transcript only; no download occurs {output_var} — S:/C: control-channel transcriptCAPTURE.{output_var} when capture is enabled remote_path is appended only for exact uppercase RETR, STOR, DELE, MKD, RMD, and CWD. local_path and output_dir are defined settings but are currently unused. Server command/auth outcomes are transcript/status results; connection failures are pipeline errors.
SSH Request
The SSH block exposes banner/command behavior through the selected command and ssh_cmd fields.
Configuration Behavior Variables Edge cases
host, port, username, password, timeout_ms command selector and ssh_cmd output_var (default SSH_RESPONSE) and capture On non-Windows builds, connects with password authentication and returns the selected command or banner transcript in output_var. Windows writes an empty output variable then returns an explicit Linux-only implementation error. banner / ssh_cmd → SSH_RESPONSE {output_var} — banner or command transcriptCAPTURE.{output_var} when capture is enabled Only exact command = exec runs ssh_cmd; blank ssh_cmd defaults to whoami. Other command values authenticate/banner only. No host-key verification setting or implementation is exposed. Connection, handshake, authentication, channel, or exec errors are pipeline failures.
IMAP Request
Mailbox and message-number fields apply only to the IMAP operations that consume them.
Configuration Behavior Variables Edge cases
host, port, username, password; use_tls; ssl_verify command: LOGIN / SELECT / FETCH / SEARCH mailbox (default INBOX), message_num, timeout_ms output_var (default IMAP_RESPONSE) and capture Authenticates and executes the selected IMAP operation against the selected mailbox/message. SELECT INBOX / FETCH 1 → IMAP_RESPONSE {output_var} — IMAP protocol response or fetched resultCAPTURE.{output_var} when capture is enabled Mailbox and message_num apply only to commands that use them. Default port 993 assumes TLS; changing use_tls changes the transport contract. Certificate failures follow ssl_verify.
SMTP Request
VERIFY and SEND_EMAIL have intentionally different side effects; the card makes that distinction explicit.
Configuration Behavior Variables Edge cases
host, port, username, password; use_tls; ssl_verify command and action: VERIFY or SEND_EMAIL from (defaults to username when empty), comma-separated to, subject, body_template output_var (default SMTP_RESPONSE) and capture VERIFY performs the login check. SEND_EMAIL uses the sender, recipients, subject, and body fields. VERIFY → SMTP_RESPONSE
SEND_EMAIL → SMTP_RESPONSE {output_var} — SMTP response/statusCAPTURE.{output_var} when capture is enabled VERIFY does not send email. SEND_EMAIL requires a valid recipient contract; do not confuse a successful transport connection with delivery. An empty from field resolves to the configured username.
POP Request
POP message operations use message_num; a normal STAT does not.
Configuration Behavior Variables Edge cases
host, port, username, password; use_tls; ssl_verify command (default STAT) and message_num for RETR / DELE output_var (default POP_RESPONSE) and capture Authenticates and executes the configured POP action, writing its result to output_var. STAT / RETR 1 → POP_RESPONSE {output_var} — POP protocol response or message resultCAPTURE.{output_var} when capture is enabled message_num only matters for RETR/DELE. Default port 995 assumes TLS. A nonnumeric or nonexistent message number is a protocol-side failure, not a parsed empty success.
WebSocket (currently unsupported)
WebSocket is a serializable protocol block in the current model, but it is categorized under Utilities and its runtime transport is not implemented yet. Its card documents the exact failure contract so imported configurations are not mistaken for working WebSocket flows.
Configuration Behavior Variables Edge cases
url, action (connect / send / receive / close), message output_var (default WS_RESPONSE) and timeout_ms The configuration is importable and serializable, but the current executor does not implement WebSocket transport. Any action → explicit unsupported-block pipeline error No output variable is produced by the current executor. Every WebSocket execution fails before using its settings with: WebSocket requires tokio-tungstenite (not yet added). Do not treat WS_RESPONSE as available until the transport dependency and executor are implemented.