The Importance of HTTP Headers
When you type a URL into a web browser, you only see the final, rendered HTML page. However, before the browser displays any text or images, the web server silently sends a block of metadata called HTTP Response Headers. These headers control critical aspects of the connection: they dictate caching policies, set cookies, confirm security certificates, establish CORS (Cross-Origin Resource Sharing) rules, and reveal the specific server software (like Nginx or Apache) handling the request.
If a website is trapped in a redirect loop, if a CDN is serving stale cache, or if an API is returning a 500 Internal Server Error, looking at the rendered web page will not help you. You must inspect the raw response headers.
The curl command in the Linux terminal is the definitive tool for fetching and analyzing these headers without the interference of a graphical web browser.
Step 1: Fetching Only the Headers
If you run a standard curl https://digitash.com command, it will download the entire HTML body of the website and dump it into your terminal, creating a massive, unreadable wall of code.
To tell curl that you only want to see the HTTP headers and you want it to ignore the HTML body completely, use the -I (capital i) flag, which stands for “fetch the HTTP-header only” (also known as a HEAD request).
curl -I https://digitash.com
The output will be clean and structured. The very first line will be the HTTP status code (e.g., HTTP/2 200 for success, or HTTP/2 404 for not found). This is immediately followed by key-value pairs showing the server type, date, content type, and caching rules.
Step 2: Viewing Headers and the Body Together
Sometimes, an API will return a 400 Bad Request error in the header, but it will also return a JSON payload in the body explaining why the request was bad. If you use the -I flag, you will miss the JSON explanation.
To view the HTTP headers and the body of the response simultaneously, use the -i (lowercase i) flag, which stands for “include headers”.
curl -i https://api.example.com/data
The terminal will output the block of headers, followed by a blank line, followed by the actual JSON or HTML payload.
Step 3: Following Redirects (The -L Flag)
A common point of confusion when checking headers is URL redirection. For example, if you query a site using plain HTTP instead of HTTPS, the server will usually issue a 301 Permanent Redirect to force you onto the secure connection.
If you run:
curl -I http://digitash.com
The output will show HTTP/1.1 301 Moved Permanently, and it will list the new URL in the Location: header. By default, curl stops right there. It does not automatically follow the redirect.
To force curl to follow the redirect chain to its final destination and show you the headers of the actual final page, append the -L (Location) flag:
curl -I -L http://digitash.com
Step 4: Debugging the Connection (The -v Flag)
If you are troubleshooting a complex issue—such as an SSL/TLS certificate failure or a proxy server problem—the standard response headers might not provide enough context. You need to see the “conversation” between your Linux machine and the server.
Use the -v (verbose) flag. It is best to use this with an empty output redirect (-o /dev/null) so the HTML body doesn’t clutter the screen.
curl -v -o /dev/null https://digitash.com
The verbose output is color-coded and highly detailed. Lines starting with * indicate actions taken by curl (like resolving the IP address or establishing the SSL handshake). Lines starting with > are the Request Headers your Linux machine sent. Lines starting with < are the Response Headers the server sent back. This provides a complete, forensic timeline of the network request.