The server currently supports only the GET method. To behave as a standards‑compliant HTTP server, it should also implement the HEAD method according to RFC 9110.
Expected behavior
- A HEAD request returns the same status code and headers as the corresponding GET request but without a message body.
- Headers such as Content-Length, Content-Type, and caching headers should still be included.
- Error responses (e.g., 404, 500) must follow the same rule: identical headers, no body.
- Connection handling should remain consistent with normal HTTP semantics.
Suggested implementation outline
- Reuse the existing GET handler to compute metadata (status, headers).
- Suppress the body before writing to the socket when the method is HEAD.
- Ensure routing logic treats HEAD as a first‑class method.
- Add automated tests verifying:
- Identical headers between GET and HEAD.
- No body is sent for HEAD.
- Correct behavior for both success and error responses.
Motivation
Supporting HEAD improves standards compliance, enables efficient metadata checks, and ensures compatibility with proxies, crawlers, and other HTTP‑aware tooling.
The server currently supports only the GET method. To behave as a standards‑compliant HTTP server, it should also implement the HEAD method according to RFC 9110.
Expected behavior
Suggested implementation outline
Motivation
Supporting HEAD improves standards compliance, enables efficient metadata checks, and ensures compatibility with proxies, crawlers, and other HTTP‑aware tooling.