Response headers

Response headers tell the client what came back and what to do with it. The status line says whether the request succeeded. The headers fill in the details: what the body contains, whether to redirect, whether to cache it, and whether to store a cookie.

Let’s pull headers from a real site. Run this:

curl -I https://flaviocopes.com/

The -I flag sends a HEAD request, so you get headers without the HTML body. You should see something like:

HTTP/2 200
content-type: text/html; charset=utf-8
content-encoding: br
cache-control: public, max-age=0, must-revalidate

Here is a typical block with labels:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Cache-Control: max-age=300

Content-Type describes the body. Content-Encoding says the body was compressed on the way. Content-Length gives its byte size when the server knows it.

Location points to another URL. You see it with redirects and with 201 Created responses. Set-Cookie asks the browser to store a cookie for later requests. Cache-Control, ETag, and Last-Modified guide caches. We cover those in the next modules.

Security headers can restrict what a browser may do with the response. We will get to those later in the course.

My advice: inspect headers in the Network panel instead of guessing. Open DevTools, reload the page, click a request, and read the Response Headers tab. A server, reverse proxy, CDN, or hosting platform may add or replace headers before they reach the client.

Be careful when a header looks wrong. If Content-Type says text/plain but the body is JSON, your client may fail to parse it. Fix the server header, or configure your client to handle the mismatch explicitly.

Try this on a site you run: compare headers on the HTML document with headers on a CSS file from the same page. Notice how caching headers often differ between them.