HEAD and OPTIONS: what they answer and what clients use them for

What it is

HEAD is, per RFC 9110, identical to GET except that the server MUST NOT send content. The server SHOULD send the same header fields it would send for GET but MAY omit fields whose value is only known while generating the content, such as Content-Length or Vary on a buffered dynamic response. A body in a HEAD request has no defined meaning and may get the connection closed as a suspected smuggling attempt. HEAD responses are cacheable and, per RFC 9111, a cache uses a HEAD response to update a stored GET response when the validators and Content-Length match, and treats it as stale otherwise.

OPTIONS requests information about the communication options for a resource, or for the server as a whole when the target is *, which RFC 9110 describes as a ping that tests capabilities without implying a resource action. A successful response SHOULD include headers that describe optional features, notably Allow; the body format is undefined; responses are not cacheable by HTTP caches; Max-Forwards can address a specific proxy in the chain. In CORS, the browser sends an OPTIONS preflight with Access-Control-Request-Method and Access-Control-Request-Headers and expects the matching Access-Control-Allow-* headers back; MDN notes that both 200 and 204 are permitted for that response but that some browsers have mishandled 204.

Why it matters

Link checkers, download managers (reading Content-Length and Accept-Ranges), uptime monitors and crawlers rely on HEAD; a framework that answers 405 to HEAD, or returns different headers than GET, makes them misreport. OPTIONS is what a browser sends before any non-simple cross-origin request; an API that answers it with 404, 401 or a redirect is unusable from browsers regardless of its CORS headers.

How to apply

• Derive HEAD from every GET route automatically; keep status, Content-Type, ETag and Last-Modified identical and skip body generation where possible.
• Apply the same authorisation to HEAD as to GET; do not leak existence of protected resources through a different status.
• Answer OPTIONS with Allow computed from the router (and include Allow in 405 responses, which RFC 9110 requires).
• Handle preflights before authentication: MDN states that preflight requests must never include credentials. Set Access-Control-Max-Age so the browser caches the result.
• Route OPTIONS * explicitly; path-based routers often turn it into a 404.

Pitfalls

A HEAD response may carry Transfer-Encoding: chunked and still have no body. Middleware that computes Content-Length by rendering the body defeats the purpose of HEAD. The CORS preflight cache and the HTTP cache are separate mechanisms; Access-Control-Max-Age, not Cache-Control, controls how long a browser keeps a preflight result.