Login - Jit4All

A user visits a page and sees what looks like a completely normal, fully-formed error message, styled consistently with the rest of the site, explaining that a record could not be found. Nothing about the page looks broken. Underneath, the server actually sent a 200 OK status, the same status used for an entirely successful page. Why would a server describe a failure to a person while telling the browser itself that nothing went wrong at all?

A status code and the visible content of a page are two separate things a server controls independently. The status code is metadata about the response, read by the browser and by tools such as search engines and monitoring scripts, while the visible page content is simply whatever HTML happens to be in the response body. A server can send a 200 OK status alongside an HTML page that describes a failure in plain English. A person reading the page sees a clear error message, while a tool checking only the status code sees a success, because nothing forced the two to agree.

Every response carries a status code, a short number stating broadly what happened: success, a redirect, a client mistake such as a missing page, or a server-side failure.

Status codes are grouped by their first digit. 200-range codes generally mean success, 300-range codes generally mean a redirect, 400-range codes mean the request itself had a problem, and 500-range codes mean the server failed while trying to handle an otherwise valid request.

A response carries headers of its own, separate from the status code and the body, such as Content-Type, telling the browser what kind of content the body actually contains.

The body of a response is whatever content the status code and headers describe. For a typical page, this is the actual HTML the browser goes on to render.

Nothing forces a response's status code, its headers, and its visible body to agree with each other in meaning. A server is free to combine them in ways that look inconsistent to a person reading the page, even though each individual piece is, on its own, a valid, well-formed response.

HTTP/1.1 200 OK
Content-Type: text/html

<html>
<body>
<h1>Record not found</h1>
<p>The item you requested does not exist.</p>
</body>
</html>

200 OK tells the browser, and any tool checking it, that the request was handled successfully. Nothing about this status code alone communicates that the page's actual content describes a failure.

Content-Type: text/html tells the browser to parse the body as HTML and render it as a page, rather than treating it as a file to download or as raw text. The browser's rendering behavior depends entirely on this header, not on what the content happens to say.

"Record not found" is plain text inside the HTML body. A person reading the rendered page understands this as a failure message immediately, with no relationship at all to the 200 status sitting above it in the response.

A script that only checks for a 200-range status to confirm a page is working correctly would report this exact response as healthy, despite it describing a missing record, because the script never reads the actual rendered content the way a person does.

Many sites instead send a 404 status alongside this same kind of not-found message, specifically so that both a person reading the page and a tool checking only the status code reach the same correct conclusion.

A 200 status paired with a body describing a failure is not an invalid or malformed response. Every individual piece is well-formed, which is exactly why this specific mismatch is easy to introduce by accident and easy to miss without specifically checking the status code separately from the page's appearance.

A monitoring script, a search engine, or another program checking whether a page works correctly very often checks only the status code, not the rendered text, which is specifically why a 200 status on a failure page can cause a broken page to be reported, and even indexed, as a normal, healthy one.

A body that is actually plain text but sent with Content-Type: text/html will still be parsed as HTML, with any characters that look like tags treated as real markup. The browser trusts this header's stated type over guessing at the content itself.

Returning an actual 404 for a missing record, instead of a 200, means a monitoring script, a search engine, and a person reading the page all correctly agree the record is missing, rather than only the person reaching that conclusion by reading the text.

A 300-range status code sent with no Location header gives the browser nothing to redirect to. The status code alone does not describe where to go next, that information lives entirely in a separate header that has to be sent alongside it.

When an AI tool describes a response, three things are worth checking. First, does it match the status code to what the page's content actually says, rather than defaulting to 200 regardless of the real outcome. Second, does it account for automated tools reading only the status code, separately from a person reading the rendered page. Third, does a described redirect include both the status code and the matching Location header, not just one of the two.

Change this lecture's example to send a 404 status instead of 200, keeping the exact same HTML body, and explain what would now correctly agree that did not before.

Find a real website's page-not-found page, check its actual status code using your browser's developer tools, and confirm whether it matches a 404 or not.

Write a Content-Type header that does not match the real content, such as labeling plain text as text/html, and describe what a browser receiving it would do with characters that happen to look like HTML tags.

Assuming an automated tool checking a page's health reads the visible content the same way a person does, rather than commonly checking only the status code.

Assuming a status code and a page's visible content are automatically kept consistent with each other, when nothing enforces that agreement at all.

You can now explain why a status code and a page's visible content are two separate things a server controls independently, and why this matters specifically for automated tools that check status codes without reading rendered text. You can also identify the broad meaning of a status code's first digit, and explain why a redirect needs both a status code and a matching header to actually work.