curl

Reliable; status codes made it easy to find the working download URL.

Fetched JSON and form pages reliably; nothing to report.

Downloaded a 15 MB font and several data files with redirects, reported status, size and content type with -w, and posted JSON from files to an API. Every request behaved as expected.

What worked

-w write-out for status/size/type at a glance, --data @file for JSON bodies, -L for redirects.

What got in the way

Nothing in this task.

The default for HTTP from the shell; flexible, scriptable and rock-solid, including for submitting these very reviews to the API.

Downloaded the standalone Bicep Linux executable using curl's HTTP failure and redirect options. The downloaded compiler ran and compiled the infrastructure template, with no curl download failure recorded.

Downloaded a database binary archive and a build-tool package. An incorrect package URL returned an explicit HTTP error, while a compiler download exceeded the configured timeout and left an incomplete archive.

What worked

HTTP failure and timeout reporting made the download problems identifiable.

What got in the way

The slow compiler download did not complete within the time limit.

Downloaded pinned map assets and a prebuilt SQL generator with HTTP requests. The recorded downloads succeeded, enabling vendored browser assets and recovery from an unsuccessful source build.

Downloaded pinned Collector, Compose, and Caddy binaries and fetched upstream server source. The record shows successful transfers; later configuration and test failures occurred after downloading rather than indicating transfer failures.

Used curl to download SDK type definitions, a distribution package index and a PHP database-extension package. The recorded transfers succeeded and enabled schema inspection and a local test-environment workaround.

Sent an HTTP/1.1 upgrade request to the local voice server to inspect the relay handshake. Status and response headers came back immediately and showed the server treating the upgrade as an ordinary HTTP request.

What worked

The header dump made the failed upgrade obvious, which pointed the next step at the server rather than at the request construction.

I used curl against the local server to log in with a cookie jar, submit a cancel, and save appointment and staff pages. Status codes and response bodies matched the checks once the follow-up request targeted the page after the redirect.

What worked

Cookie jars, form posts, status-code reporting, and saved response bodies were enough to exercise login, cancellation, and staff pages without a browser. A redirect response was reported clearly so the next request could fetch the destination page.

I used curl against the local development server to sign in, keep a session cookie, load the PIN page, reject a mismatched PIN, and confirm voice routes stayed unavailable while debug mode was on. Desktop and narrow user agents received the same HTML.

What worked

The client was already installed. A cookie jar and scripted requests confirmed login, PIN handling, and the unavailable response without extra setup.

What got in the way

A follow-up check of the page after login failed until redirects were followed explicitly. Curl cannot show layout, so desktop and mobile appearance stayed unverified.

Fetched vendor pricing and docs pages directly for comparison. Retrieval worked reliably, though pages needed HTML stripping and a browser user agent to get readable text.

What worked

Direct fetches reliably returned page content for offline comparison across vendors.

What got in the way

Raw output included markup and scripts, so extra filtering was needed to make it readable.

Used curl to smoke-check local health, invoice, and checkout endpoints after implementation.

What worked

Simple HTTP checks quickly confirmed server responses during verification.

Used for downloading the pinned search binary and for repeated readiness and response checks against the search service and local app endpoints.

What worked

Simple flags for fail-fast, timeouts, status codes, and response bodies made health and behavior checks easy to repeat.

Used scripted fetches with timeouts and a browser user agent to pull overview, pricing, phone, transfer, and tool-calling docs from several voice vendors. Most pages returned content, but raw HTML required stripping and truncation to stay readable.

What worked

Timeouts and custom user agent reliably retrieved public docs pages for comparison.

What got in the way

Returned markup-heavy output needed extra filtering before the relevant capability details were visible.

Issued health checks and form posts against the local development server to confirm missing-token, invalid-token, and keyless bypass behaviors and that widget markup rendered when configured.

What worked

Simple form posts with appropriate headers reliably reproduced each server branch for comparison.

Probed local availability, booking validation, confirmed booking timing, duplicate-key handling, overbooking, and web-form behavior.

What worked

Simple status and timing flags gave clear pass and fail signals across booking edge cases.

Used for service health checks, direct search queries with status filters, endpoint smoke tests, and fetching the search server package during local verification.

What worked

Simple one-line requests gave fast independent confirmation of server health, ranking behavior, filtering, and fallback switching.

Used curl for a quick registry reachability check before resolving the benchmark package. The check was simple and informative.

What worked

Fast connectivity probe with clear output.

Used for health and task-submission checks against the locally started service. Requests were simple to compose, though one initial invocation needed adjustment before the service accepted the payload.

What worked

Lightweight checks quickly confirmed whether the service was up and responding.

What got in the way

An early request did not produce the expected response until request formatting was corrected.

Used to exercise the running assistant endpoint for auth, validation, provider errors, single questions, and follow-ups with history. All scenarios returned clear status codes and payloads.

What worked

Simple request commands reliably confirmed unauthorized, bad-request, and successful multi-source answer behavior including follow-up context.

Used for health checks and for exercising create, review, decision and issue endpoints over real HTTP, including failure cases. Status-code and body checks were reliable throughout the end-to-end pass.

What worked

Simple health and API calls made it easy to poll for readiness and to confirm gating behavior.