About This Article
This article is organized based on the official curl documentation and HTTP specifications.Verification Status: Verified against official specifications. Connection-dependent details are variable.
HTTP header values vary depending on the connection destination and time. This article focuses on how to read them rather than expecting specific values.
curl -I is an entry point for checking the metadata of an HTTP response returned by a web server. You do not need to memorize all headers at once. Simply reviewing Status, Content-Type, Content-Encoding, Cache-Control, and Content-Length in order makes investigating web servers much easier.
- What curl -I Sends
- The First Five Items to Check
- Do Not Assume the Site Is Healthy Based on Status Alone
- What Does Content-Type Return?
- Check Content-Encoding to Verify gzip
- Cache-Control Is More Than Just Caching or Not Caching
- Content-Length May Sometimes Be Absent
- Do Not Confuse -I and -i
- Connecting to Nginx Investigation
- Summary
- Official and Primary Sources
What curl -I Sends
The -I / –head option for an HTTP URL uses a HEAD request.
curl -I https://example.com/
sequenceDiagram
participant C as curl
participant S as Web server
C->>S: HEAD /
S-->>C: Status + Header fields
Note over C,S: response bodyは送信しない
HEAD is an HTTP method used to retrieve metadata corresponding to GET without the response body. Therefore, the result of curl -I and an actual GET request are not always identical character for character.
The First Five Items to Check
Conceptually, you read output like the following.
HTTP/2 200 content-type: text/html; charset=UTF-8 content-encoding: gzip cache-control: max-age=300 content-length: 12345
| Item | What to Check |
|---|---|
| Status | Result of the request |
| Content-Type | Representation type, such as HTML, JSON, or JavaScript |
| Content-Encoding | Content coding such as gzip |
| Cache-Control | Caching instructions |
| Content-Length | Information regarding representation length |
flowchart LR
A[HTTP response] --> B[Status]
B --> C[Content-Type]
C --> D[Content-Encoding]
D --> E[Cache-Control]
E --> F[Content-Length]
Do Not Assume the Site Is Healthy Based on Status Alone
A 200 status indicates that the HTTP request succeeded. However, it does not imply that all internal application features are functioning normally or that the database is healthy.
Conversely, 301 and 302 are redirects to another URL and do not necessarily represent an error.
What Does Content-Type Return?
content-type: text/html; charset=UTF-8
In this example, the representation is HTML, with UTF-8 specified as the charset. For API investigations, it will be application/json, and for JavaScript, it may be text/javascript or application/javascript, depending on the target.
Check Content-Encoding to Verify gzip
Even if gzip is enabled on the web server, not all responses are guaranteed to be gzipped. Factors such as the requester's Accept-Encoding, Content-Type, size, and server configuration play a role.
If you want to verify a request that accepts compression, you can explicitly specify it as follows, for example.
curl -sS -D - -o /dev/null -H 'Accept-Encoding: gzip' https://example.com/
If the response contains the following, the gzip content coding is being used.
content-encoding: gzip
Cache-Control Is More Than Just Caching or Not Caching
Cache-Control includes multiple directives such as max-age, no-cache, and no-store. Because each has a different meaning, simply remembering that "it contains no-cache, so it is not cached" can easily lead to misunderstandings.
When investigating HTTP caching, read alongside RFC 9111.
Content-Length May Sometimes Be Absent
Just because Content-Length is not displayed in a HEAD response does not immediately mean there is an anomaly. Visible information changes depending on the transfer method, dynamic generation, HTTP version, and server implementation.
It is safer to "read the meaning from the headers actually returned" rather than "searching for a header that should be there."
Do Not Confuse -I and -i
-I: Sends HEAD in HTTP and checks response headers
-i: Displays headers along with the body in a normal response
If you want to view the actual response during a GET request, options like -i or -D – are candidates.
curl -i https://example.com/
Connecting to Nginx Investigation
When investigating gzip or caching in Nginx, do not rely solely on configuration files; ultimately, use curl to verify how they appear in the HTTP response.
flowchart LR
A[Nginx設定] --> B[リクエスト]
B --> C[レスポンス]
C --> D[Content-Type]
C --> E[Content-Encoding]
C --> F[Cache-Control]
D --> G[設定と実測を照合]
E --> G
F --> G
Verifying configuration values and actual responses separately helps isolate issues, such as discovering that "the configuration was written, but it is not applied to the target response."
Summary
curl -I uses a HEAD request in HTTP
Read only the Status and primary headers first
Focus on Content-Encoding for gzip and Cache-Control for caching
HEAD and GET have different purposes, so check the GET side as well if necessary
Cross-reference configurations and actual HTTP responses when investigating web servers
Official and Primary Sources
curl command line tool and library — manual
https://curl.se/docs/manpage.html
RFC 9110 — HTTP Semantics
https://www.rfc-editor.org/rfc/rfc9110.html
RFC 9111 — HTTP Caching
https://www.rfc-editor.org/rfc/rfc9111.html
