Request headers vs response headers in HTTP, using ETag

Request headers are sent by the client to describe the request context, preferences or conditions. Response headers are sent by the server to describe the response metadata or instructions. In the ETag flow specifically: the server includes an ETag in the response; clients then use conditional request headers like If-None-Match or If-Match on later requests. Matching tags let the server return 304 Not Modified without a body or reject conflicting writes with 412 Precondition Failed (MDN: HTTP headers, MDN: ETag).

Where ETag fits: caching and concurrency

ETag is a response header that identifies a specific representation of a resource. When the resource changes, the server must generate a new tag. Comparing tags lets a client and server decide if two representations are the same. This enables efficient caching and safe overwrite protection (MDN: ETag).

ETags can be strong or weak. Weak tags are easier to generate but are not byte-for-byte identical and are less useful for comparisons; they also prevent caching when byte range requests are used. Strong ETags are ideal for exact comparison and compatible with range caching (MDN: ETag).

Example: Conditional GET with ETag (caching)

GET /articles/42 HTTP/1.1
Host: api.example.test
Accept: application/json

HTTP/1.1 200 OK
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
Content-Type: application/json

{"id":42,"title":"ETag intro"}

Later, the client revalidates its cached copy by sending the ETag value in a request header:

GET /articles/42 HTTP/1.1
Host: api.example.test
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

HTTP/1.1 304 Not Modified

If the tag matches the server’s current version, the server returns 304 Not Modified with no body, allowing the client to reuse its cached representation (MDN: ETag). For more on the status code, see What does HTTP code 304 mean?.

Example: Prevent conflicting updates with If-Match (concurrency)

GET /articles/42 HTTP/1.1
Host: api.example.test

HTTP/1.1 200 OK
ETag: "33a64df..."

The client includes the ETag in a conditional write to ensure it only updates the version it read:

PUT /articles/42 HTTP/1.1
Host: api.example.test
If-Match: "33a64df..."
Content-Type: application/json

{"title":"ETag intro (edited)"}

If the server’s current ETag differs (someone else edited in the meantime), it rejects the write with 412 Precondition Failed (MDN: ETag). For troubleshooting this status, see How to fix 412 Precondition Failed.

Common request vs response headers in this flow

Request headers (client to server)

• If-None-Match: asks the server to send the body only if the resource has changed since the supplied ETag. If it has not, the server can reply 304 (MDN: ETag).
• If-Match: applies the method only if the resource matches one of the given ETags; used to prevent overwriting concurrent edits (MDN: ETag).
• Accept: indicates the media types the client can accept; the server chooses and reports the result with Content-Type (MDN: Accept).
• Content-Type (when sending a body): states the media type of the request payload, e.g., application/json. Servers may reject unsupported types with 415 (MDN: Content-Type).

Response headers (server to client)

• ETag: the server’s identifier for the current representation (MDN: ETag).
• Content-Type: media type of the returned data, e.g., application/json (MDN: Content-Type).

Put this into practice

Capture a redacted request and response pair and label the direction of each header. Follow the conditional request through its result; a header name can appear in an explanation without being valid in every direction.

ETag rollout checklist: requests vs responses

• Return a strong ETag for cacheable representations that may be revalidated.
• On GET/HEAD, compare If-None-Match and return 304 Not Modified when the tag matches.
• On PUT/PATCH/DELETE, require If-Match to prevent lost updates; return 412 on mismatch.
• Use strong ETags if you rely on byte range requests; weak ETags prevent caching with ranges.
• Document which endpoints emit ETag and which expect conditional headers, then test with real requests.

FAQ

Do clients ever send ETag? No. ETag is a response header. Clients send If-None-Match or If-Match in requests to use the server-supplied tag (MDN: ETag).

Can Content-Type appear in both directions? Yes. In responses, it tells the client the media type of the body. In requests with a body (e.g., POST/PUT), it tells the server what type is being sent; servers may return 415 if they do not accept it (MDN: Content-Type).

Is Accept a request or response header? It can legally appear in both, but in practice it is most used in requests to drive content negotiation, with the server indicating its final choice in Content-Type (MDN: Accept).