curlMake HTTP requests and debug APIs
curl sends a request to a URL and prints the response. It speaks HTTP(S) and many other protocols, can set any method, header or body, and can show every step of the connection with timings: the standard tool for testing APIs, health checks and TLS.
curl [-sSfLiIv] [-X METHOD] [-H 'Header: v'] [-d DATA] [-o FILE] [-w FORMAT] URL...You've just deployed. Check the health endpoint answers, then look at the status and headers the site returns.
curlClient for URLs: opens the connection, sends the request, writes the response body to stdout.
curl (built on libcurl) parses the URL, then resolves the host through getaddrinfo, so /etc/hosts and DNS both apply. It opens a TCP connection to the port (80 for http, 443 for https), trying IPv6 and IPv4 addresses in turn. For https it runs a TLS handshake: it sends the host name as SNI and offers ALPN h2 and http/1.1, receives the server's certificate chain and verifies it against the CA bundle in /etc/ssl/certs, including that the name matches the certificate's subjectAltName. Then it sends the request line, headers (Host, User-Agent, Accept and yours) and any body, and reads the status line, headers and body. The body goes to stdout and the progress meter and errors to stderr, so pipes get clean data. curl does not follow redirects unless you add -L, and by default treats a 404 or 500 as success (exit 0); -f makes HTTP errors fail with exit 22. -w prints timings for each phase.
curl resolves the name, opens TCP, runs the TLS handshake and verifies the certificate, then sends the request; -w times every phase.
curl parses the URL and asks getaddrinfo for api.devops-lab.io, so /etc/hosts is checked first, then DNS. It gets two IPv4 addresses.
-s / -SSilent (no progress meter) / still show errors when silent-fFail on HTTP 400+ with exit code 22 and no body (for scripts)-LFollow redirects (301, 302, 307, 308)-i / -IInclude response headers / send HEAD and show only headers-vVerbose: DNS, connect, TLS handshake, request and response headers-X METHODRequest method: GET, POST, PUT, PATCH, DELETE-H 'K: V'Add or override a request header (repeatable)-d DATA / --jsonSend a body (POST); --json also sets JSON headers (curl 7.82+)-o FILE / -OWrite body to FILE / to a file named like the URL-w FORMATPrint variables after the transfer: %{http_code}, %{time_total}...-u user:passHTTP basic authentication--resolve h:p:ipForce host:port to an IP, bypassing DNS (test one backend)--connect-timeout / -mLimit connect time / the whole operation, in seconds--retry NRetry transient failures N timescurl -k https://internal-api/ in scripts to 'fix' certificate errors-k disables all verification, so anyone in the path can impersonate the server and read tokens.
curl --cacert /etc/ssl/certs/internal-ca.pem https://internal-api/if curl -s $URL; then echo healthy; ficurl exits 0 on 404 and 500 responses: only transport errors fail.
curl -fsS -o /dev/null $URL && echo healthycurl -o app.tar.gz https://host/latest (behind a redirect)Without -L you save the tiny 301/302 page, not the file, and later tar fails with a confusing error.
curl -fL -o app.tar.gz https://host/latestcurl -u admin:S3cret https://api/... typed on the command linePasswords and tokens in arguments end up in shell history and in ps output for other users.
Read from a variable or a file: curl -H @headers.txt ... or -u admin (curl prompts)Health checks without timeoutsA dropped SYN makes curl wait for the kernel's TCP timeout, over two minutes, and the check hangs.
curl -fsS --connect-timeout 3 -m 10 http://host/healthTry these on a Linux machine of your own. Each task has a hint and a solution.
Is anything listening on port 80 of this sandbox? Request http://localhost/ with curl and read the result or the error code.
Print only the HTTP status code returned by http://localhost/, without the body or progress meter.
Write a curl command that POSTs {"name":"devops"} as JSON to http://localhost:8080/users and fails with a non-zero exit code on any HTTP error.
Request a URL on a closed port (http://localhost:9/) and explain the exit code.
curlMake HTTP requests and debug APIs
curl sends a request to a URL and prints the response. It speaks HTTP(S) and many other protocols, can set any method, header or body, and can show every step of the connection with timings: the standard tool for testing APIs, health checks and TLS.
curl [-sSfLiIv] [-X METHOD] [-H 'Header: v'] [-d DATA] [-o FILE] [-w FORMAT] URL...You've just deployed. Check the health endpoint answers, then look at the status and headers the site returns.
curlClient for URLs: opens the connection, sends the request, writes the response body to stdout.
curl (built on libcurl) parses the URL, then resolves the host through getaddrinfo, so /etc/hosts and DNS both apply. It opens a TCP connection to the port (80 for http, 443 for https), trying IPv6 and IPv4 addresses in turn. For https it runs a TLS handshake: it sends the host name as SNI and offers ALPN h2 and http/1.1, receives the server's certificate chain and verifies it against the CA bundle in /etc/ssl/certs, including that the name matches the certificate's subjectAltName. Then it sends the request line, headers (Host, User-Agent, Accept and yours) and any body, and reads the status line, headers and body. The body goes to stdout and the progress meter and errors to stderr, so pipes get clean data. curl does not follow redirects unless you add -L, and by default treats a 404 or 500 as success (exit 0); -f makes HTTP errors fail with exit 22. -w prints timings for each phase.
curl resolves the name, opens TCP, runs the TLS handshake and verifies the certificate, then sends the request; -w times every phase.
curl parses the URL and asks getaddrinfo for api.devops-lab.io, so /etc/hosts is checked first, then DNS. It gets two IPv4 addresses.
-s / -SSilent (no progress meter) / still show errors when silent-fFail on HTTP 400+ with exit code 22 and no body (for scripts)-LFollow redirects (301, 302, 307, 308)-i / -IInclude response headers / send HEAD and show only headers-vVerbose: DNS, connect, TLS handshake, request and response headers-X METHODRequest method: GET, POST, PUT, PATCH, DELETE-H 'K: V'Add or override a request header (repeatable)-d DATA / --jsonSend a body (POST); --json also sets JSON headers (curl 7.82+)-o FILE / -OWrite body to FILE / to a file named like the URL-w FORMATPrint variables after the transfer: %{http_code}, %{time_total}...-u user:passHTTP basic authentication--resolve h:p:ipForce host:port to an IP, bypassing DNS (test one backend)--connect-timeout / -mLimit connect time / the whole operation, in seconds--retry NRetry transient failures N timescurl -k https://internal-api/ in scripts to 'fix' certificate errors-k disables all verification, so anyone in the path can impersonate the server and read tokens.
curl --cacert /etc/ssl/certs/internal-ca.pem https://internal-api/if curl -s $URL; then echo healthy; ficurl exits 0 on 404 and 500 responses: only transport errors fail.
curl -fsS -o /dev/null $URL && echo healthycurl -o app.tar.gz https://host/latest (behind a redirect)Without -L you save the tiny 301/302 page, not the file, and later tar fails with a confusing error.
curl -fL -o app.tar.gz https://host/latestcurl -u admin:S3cret https://api/... typed on the command linePasswords and tokens in arguments end up in shell history and in ps output for other users.
Read from a variable or a file: curl -H @headers.txt ... or -u admin (curl prompts)Health checks without timeoutsA dropped SYN makes curl wait for the kernel's TCP timeout, over two minutes, and the check hangs.
curl -fsS --connect-timeout 3 -m 10 http://host/healthTry these on a Linux machine of your own. Each task has a hint and a solution.
Is anything listening on port 80 of this sandbox? Request http://localhost/ with curl and read the result or the error code.
Print only the HTTP status code returned by http://localhost/, without the body or progress meter.
Write a curl command that POSTs {"name":"devops"} as JSON to http://localhost:8080/users and fails with a non-zero exit code on any HTTP error.
Request a URL on a closed port (http://localhost:9/) and explain the exit code.