The response: status line, codes, and content types — COMP 348

The status line

A response mirrors a request: one status line, header lines, a blank line, then the body. The status line is three tokens:

HTTP/1.1 404 Not Found

the version the server is speaking, a three-digit status code, and a human-readable reason phrase. Programs branch on the number. The phrase is for people reading a telnet transcript, and a server may write anything sensible there — 404 Nope is legal and equally well understood by every client, because no client reads it.

The five families

The first digit is a contract that holds in every version of HTTP:

1xx informational — a provisional reply; more is coming. 100 Continue lets a client ask before uploading something large.
2xx success — the request worked. 200 OK is almost the whole family in practice.
3xx redirection — the resource is elsewhere, or the client’s cached copy is fine.
4xx client error — you asked wrongly. Fix the request, not the server.
5xx server error — the request was fine and the server broke.

That 4xx/5xx split is the one to keep. It assigns blame, and it tells a client whether retrying the identical request could ever help. Retrying a 404 is pointless; retrying a 503 is reasonable.

The codes a server actually emits

Harold’s table runs to sixty codes. A file server needs about five. 200 when the file was found. 400 when the request line did not parse. 403 when the path resolved outside the document root. 404 when nothing is there. 501 when the method is something you do not implement — a server that only does GET and HEAD answers 501 to a PUT, not 400, because the request was well-formed and merely unsupported. Add 301 and 302 if you redirect, and 304 if you honour If-Modified-Since.

Java names them for you: HttpURLConnection.HTTP_OK is 200, HTTP_NOT_FOUND is 404, HTTP_NOT_IMPLEMENTED is 501. Use the constants when reading; write the literal number when generating, because you are producing wire text, not calling an API.

What the client side was branching on

Module 4 had you call getResponseCode() and branch at 400 without saying why 400. This is why. 400 is exactly the line where blame arrives: below it the response is the resource you asked for — 2xx delivered it, 3xx says where it moved — so the body belongs on getInputStream(). At 400 and above the body is no longer the resource; it is the server explaining why there is not one, which is precisely why HttpURLConnection moves it to getErrorStream() and lets getInputStream() throw.

So the mechanical rule you already coded against has a meaning, and the meaning is what makes an error message worth printing. A client that reports 404 Not Found has told its user something actionable — the path is wrong, do not retry. A client that reports IOException for the identical event has told them nothing, and cannot distinguish it from a dead host. And the first digit tells you whether retrying could ever help: never for a 4xx, quite possibly for a 5xx.

MIME media types

Content-Type carries a MIME media type: a general type, a slash, and a specific subtype — text/html, image/jpeg, application/pdf. Eight top-level types exist: text, image, audio, video, model, application, message, and multipart. Subtypes are open-ended, and anything nonstandard is conventionally prefixed x-, as in application/x-shockwave-flash.

Text types take a parameter that matters more than it looks: charset. Content-Type: text/html; charset=UTF-8 is the only thing telling the client how bytes become characters. Omit it and the client guesses, usually wrongly, and a page of accented names turns to mojibake.

Worked example — one 404, field by field

HTTP/1.1 404 Not Found
Date: Mon, 03 Aug 2026 12:07:55 GMT
Server: TinyFileServer/0.1
Content-Type: text/html; charset=UTF-8
Content-Length: 48
Connection: close

<html><body><h1>404 Not Found</h1></body></html>

The status line assigns blame to the client. Content-Type promises HTML in UTF-8 — so the client renders the error rather than downloading it. Content-Length: 48 counts exactly the body bytes below the blank line, header excluded. Connection: close says the socket goes away next.

The important observation is that this is a complete, well-formed response. A missing page is not an exception; it is an ordinary answer with a different number in it. Servers that report failures by writing a body with no status line, or by dropping the connection, are the ones whose clients hang.

The first digit is the contract: 4xx says the client is at fault, 5xx says the server is. Five of these carry a file server — 200, 400, 403, 404 and 501 — and every one of them must go out as a complete response: status line, headers, blank line, body.