The Gold Standard of Websites | Separating Fetch Rejection from an HTTP Error Response

Imagine an explanation panel requesting record C17. It needs a usable response, a status permitted by the endpoint's contract, a body in the expected format and a record whose identifier matches C17. It also needs permission to render into the panel that is current when the result becomes available.

The fetch call returns a promise. Fulfilment supplies a Response object under the API's rules; rejection follows its failure path. Neither settlement is a complete statement about every later body operation or the catalogue's own interpretation of the data.

Keep a small outcome ledger. First record whether the fetch promise fulfilled or rejected. If it fulfilled, record the exposed response type and status. Then record body consumption, parsing, data validation and final display permission separately. A failure at one layer should not silently become a success at another.

For C17, a readable 404 response can give a clear missing-resource message. A network failure can give no readable response at all. Both may prevent the explanation from appearing, but their available evidence and sensible next steps differ. A single catch label called record missing would misdescribe one of them.

The lesson begins with this distinction because otherwise a repair becomes accidental. Adding a catch handler cannot make HTTP status checks appear automatically. Adding a status check cannot ensure the body parses. A dependable client expresses each boundary that matters for its actual task.

Contents · Next chapter

In the first case, the local teaching endpoint receives the request and returns status 404 with a small JSON body describing the absent catalogue record. The exchange is readable by the client. The fetch promise fulfils with its Response rather than rejecting merely because the status is 404.

After awaiting fetch, the code can inspect response.status and response.ok. For this response, status is 404 and ok is false. If the code goes directly to response.json without checking status, the body can parse successfully and produce the endpoint's error record.

Successful parsing has not turned the missing record into an explanation. The resulting object may contain an error field instead of the requested title and explanation. If a renderer accepts any parsed object, it can display a blank or misleading panel while reporting that the load succeeded.

A deliberate policy branches on the response status before treating the body as successful catalogue data. It can still read an error body through an appropriate bounded diagnostic path. The status and diagnostic payload are complementary evidence; neither should be ignored because the other exists.

The changed-context check is a 500 response with valid JSON. The fetch promise can again fulfil. Its body may explain a server problem, but the application should not classify it as a missing C17 record simply because both cases had ok false. HTTP categories and endpoint-specific meanings still matter after the initial boundary is recognised.

Contents · Previous chapter · Next chapter

The Fetch Standard defines an ok status as the inclusive range 200 through 299. The Response ok getter reports whether the exposed status is in that range. It is a convenient status-family test, not a validation of body syntax, record identity, freshness or successful completion of a business process.

For ordinary readable responses, 200 gives ok true, 204 gives ok true, 404 gives ok false and 503 gives ok false. These values follow the status test. They do not depend on whether the body contains an optimistic sentence or a JSON member named success.

An endpoint contract may need a narrower policy. A catalogue request that expects a complete representation might accept 200 while treating a particular other status as a distinct workflow state. Conversely, a documented response outside the successful family can carry useful information without being accepted as the requested representation.

For a paper exercise, suppose an endpoint returns 202 to acknowledge a queued explanation-generation job. ok is true, but the final explanation is not necessarily ready. The client must follow the endpoint's documented completion route if it needs that final result. The boolean does not convert acceptance into completion.

Do not repair this by changing the meaning of ok in your explanation. Preserve the platform definition and name the application's further condition. A clear client can say status accepted, body valid, record matched and job completed as separate facts. That is more informative than a single success variable whose meaning changes from line to line.

Contents · Previous chapter · Next chapter

Some code deliberately throws after seeing an unacceptable status. In that design, a surrounding catch can receive an application-created error for HTTP 404. The catch behaviour is real, but it was introduced by the status policy, not by fetch automatically rejecting every unsuccessful HTTP status.

Use two labelled cases. Case A awaits fetch and then reads status without throwing. A readable 404 reaches the status-handling branch. Case B awaits fetch, checks response.ok and throws an application error when it is false. The derived asynchronous operation in B rejects through that explicit throw.

If the same catch handles both network rejection and the application's status error, preserve enough information to distinguish them. Otherwise the interface may tell the reader to check their connection when the server has clearly answered that C17 does not exist.

The reverse mistake is also possible: treating every catch as a confirmed HTTP error. A rejected fetch may not supply a Response that script can inspect. Inventing a status such as 404 in that branch would add evidence the client never received.

For a useful review, point to the exact statement that establishes each rejection. Was it fetch's own failure path, an explicit status-policy throw, body parsing or a later validator? The catch location alone cannot answer. It merely identifies where several different failures may have been collected.

Contents · Previous chapter · Next chapter

In the second catalogue case, the endpoint returns HTTP 200 and declares a JSON representation, but its body is malformed. The fetch promise fulfils, status is 200 and ok is true. Calling response.json starts a separate consumption and parsing operation that rejects when the bytes cannot be parsed as JSON.

The final catch can therefore run even though the HTTP status was successful. This does not mean fetch changed a 200 into a network failure. The ledger has two entries: response obtained successfully, then JSON interpretation failed. They describe a sequence rather than contradictory outcomes.

For an original minimal fixture, use a body consisting of an opening brace followed by incomplete text. Do not substitute a valid empty object, because that would test data validation rather than JSON syntax. A meaningful test changes one layer while holding the others fixed.

A Content-Type declaration is useful evidence about intended representation, but it cannot make malformed bytes parse. Conversely, response.json performs JSON parsing; a client should not assume that this method itself enforces every media-type rule the application wants. Check the declared type under the endpoint contract when that matters.

The transfer case is a 200 HTML login page returned through an unexpected route. A JSON-consuming client may fail at parsing, while a permissive text renderer could display the wrong content. The repair is to validate the response contract and handle the actual failure stage, not to relabel every parsing error as an absent catalogue record.

Contents · Previous chapter · Next chapter

Now let the body parse perfectly into an object with identifier C23, although the request was for C17. Syntax has passed. The catalogue's semantic requirement has not. A client that verifies only status and JSON syntax can still display the wrong explanation.

The original task gives a simple acceptance check: the response must contain the expected fields with permitted types and the intended record identifier. Apply the actual endpoint schema rather than inventing a universal validator. A number where a string is required is a different defect from a missing field or an unexpected identifier.

For the paper ledger, record status 200, ok true, JSON parsed, identifier C23 and requested identifier C17. The first failed catalogue condition is the identity comparison. Do not rewrite the earlier entries as HTTP failure; keeping them intact helps locate the defect.

A field named success can be part of an endpoint's documented payload, but it is not a platform-wide proof. Even a true value has to be interpreted within that endpoint's contract. It cannot override a contradictory status policy, missing required data or a mismatch with the current request.

This is also where the client's requested input matters. If a button's identifier changed while an event handler waited, the wrong request may have been sent before the response arrived. The deferred-event guide explains how to capture intended inputs. Response validation is useful, but it cannot by itself decide which activation the author meant to represent.

Contents · Previous chapter · Next chapter

A 204 response belongs to the ok status family and has no response body under the relevant HTTP and Fetch rules. That can be entirely appropriate for an endpoint operation whose successful contract requires no returned representation. It is not equivalent to a valid JSON document containing an empty object or an empty list.

If the client blindly calls response.json on such an empty response, JSON parsing cannot produce an ordinary JSON value from the absent content. The resulting rejection is a body-interpretation issue introduced by asking for a representation the contract did not provide.

For a catalogue delete operation, a documented 204 may mean the operation completed without a body. A catalogue lookup that requires a complete explanation record has a different contract. The client should not display an empty explanation as though it had validated a representation merely because ok was true.

Compare three fixtures: 200 with the JSON text [], 200 with malformed or empty JSON content, and 204 with no body. The first can represent a valid empty list under a suitable schema. The second fails the intended JSON interpretation. The third requires status-specific handling under the operation's contract.

The practical habit is to decide whether a body is expected before consuming it as a particular format. That decision can depend on method, status and endpoint semantics. An unconditional parse after every successful-family response is simpler to type but can erase distinctions that the actual API deliberately expresses.

Contents · Previous chapter · Next chapter

Receiving the Response does not establish that all body bytes have already been consumed and validated by application code. The body has its own stream and consumption rules. A body read can fail after response availability, for example when the stream errors or the requested interpretation cannot be completed.

This matters for progress messages. A panel that announces explanation loaded immediately after await fetch may be speaking before it has read the explanation. A more accurate sequence marks response received, then content processed, then explanation ready after the relevant validation succeeds.

Ordinary response bodies are not reusable bags of bytes. Consuming a nonempty body through json and then trying to consume that same body again through text is not a general fallback strategy. The disturbed or locked state constrains later consumption. Design a single intended read or an appropriate deliberate clone before consumption where justified.

The teaching check uses one local response, consumes its JSON and then attempts another read of that same nonempty body. The second read is rejected in the controlled runtime. This verifies the boundary without claiming that every special response with a null body has identical observable details.

For a real client, avoid reading an error body once for logging and then again for the message without planning ownership of that read. A helper can return the already interpreted bounded diagnostic value. The important record is what was consumed and by whom, not merely whether the Response object still exists.

Contents · Previous chapter · Next chapter

Browser fetch can expose an opaque filtered response in relevant cross-origin no-cors situations. Its script-visible status is zero, its headers are not exposed as an ordinary readable set and its body is null in the filtered view. This is a restricted view, not an HTTP server sending a normal status code zero.

Consequently response.ok is false for that exposed status. But that value does not identify the underlying HTTP status or prove that the remote resource is absent. The information is intentionally unavailable through this view. An application needing readable catalogue JSON has not obtained its required evidence.

Changing a request to no-cors is therefore not a general repair for a blocked JSON API request. It can remove the very visibility the client needs to inspect status, headers and body. The appropriate integration requires a permitted request and response contract, not a promise to infer hidden contents.

An opaque-redirect filtered response is another restricted response kind with a zero exposed status under its own conditions. Keep the response type in the diagnostic record. A number alone cannot distinguish every platform state that uses this exposed value.

These cases are explained from the Fetch Standard. The local Node server tests do not verify browser CORS filtering or no-cors behaviour. A browser-specific reproduction needs the actual origins, request mode and response headers. Treating a successful loopback test as evidence for those restrictions would exceed what the experiment contains.

Contents · Previous chapter · Next chapter

A fetch rejection can arise from different conditions, including network-related failure, platform restrictions or abortion. Script may not receive a readable Response that reveals the remote status. A catch handler should therefore avoid asserting a specific server-side cause without additional evidence.

For example, a connection problem and a browser CORS failure can both prevent the intended readable response from reaching the consuming code. A generic JavaScript error alone does not prove which infrastructure component failed. Browser diagnostics, controlled reproductions or service-side records may be needed to distinguish explanations.

The catalogue can tell the reader that the explanation could not be obtained, while its diagnostic path records the stage and available error information. It should not invent a missing record, a denied account or a confirmed server outage merely because one catch branch handled the failure.

Abortion deserves its own context. A deliberately supplied signal can end local fetch handling under its rules. The application can retain its cancellation cause separately rather than replacing it with an unexplained connection message. A combined signal's reason also follows a specific ordering contract, covered in the connected cancellation lesson.

Keep uncertainty useful: name what was observed and what would distinguish the remaining causes. A readable 404 gives more specific evidence than no readable response. A failed JSON parse after a readable 200 gives a different evidence pattern again. Correct classification makes the next check smaller and the user-facing message more accurate.

Contents · Previous chapter · Next chapter

A small helper can expose the sequence clearly: await the response, classify its type and status, choose the permitted body handling, validate the resulting record and return accepted catalogue data. The caller then decides whether that data may update the current panel. This is a design outline, not one universal status policy for every endpoint.

If the helper throws for an unacceptable status, include a safe structured distinction between an HTTP-status rejection and other failures. Preserve the status value and the intended operation identity without indiscriminately retaining private payloads. A later handler should not have to guess the category by searching the English text of an error message.

For C17, the helper can return a documented missing-record outcome for a readable 404, reject malformed successful data separately and pass through a genuinely accepted explanation. That allows the interface to offer appropriate next steps without treating all non-success states as a broken connection.

Be careful with a catch that returns an empty list. It changes the derived operation into a fulfilled value. If that fallback is intentional, label it and preserve the failure distinction needed by the product. Otherwise a network failure can silently become evidence that the catalogue contains no explanations.

Test the helper with a matrix of fixtures that differ at one boundary: 404 valid error JSON, 200 invalid JSON, 200 wrong identifier and 200 valid C17. The accepted-data path should receive only the final case under the stipulated contract. A catch handler's mere presence is not evidence that the matrix has been handled correctly.

Contents · Previous chapter · Next chapter

Suppose a complete catalogue panel needs three requests: title, explanation and related items. If each input to Promise.all is only the raw fetch promise, a readable 404 from the explanation request can fulfil its input with a Response. The aggregation mechanism sees a fulfilled input, not the catalogue's semantic failure.

The combined promise can therefore fulfil with three Response objects even though one is unsuitable for the intended display. Promise.all does not inspect response.ok or parse each body on behalf of the author. Its aggregation contract and the HTTP acceptance contract remain separate.

Change each input into an operation that performs the appropriate status and body checks before fulfilling with accepted data. Now the explanation operation can reject under its explicit policy, and the aggregate can reject accordingly. This is a change in the input operations' contract, not a new ability inside Promise.all.

Even then, aggregate rejection does not automatically cancel the other operations. They may continue to consume bodies or complete work unless the application and APIs cooperate through a separate mechanism. The connected aggregation lesson develops that remaining-work trace in full.

For the changed-context exercise, make related items optional. The product might accept a title and explanation while reporting that related items were unavailable. That is an application policy with a different combined requirement. Do not smuggle it in by converting every failed request into an empty array and then describing the entire panel as fully verified.

Contents · Previous chapter · Next chapter

A supplied abort signal can end local waiting or body handling according to the relevant stage and API rules. It does not establish that a remote operation was never received or applied. This distinction is especially important when a fetch represents a state-changing request rather than a catalogue read.

Imagine a bookmark submission. The server accepts the bookmark, but the client stops waiting before it receives usable confirmation. A local rejection or timeout can coexist with a saved bookmark. Repeating the submission without checking the operation's replay contract can create an unintended second effect.

Keep a stable application operation identity where the service supports reconciliation, and use its documented status or readback route when completion is uncertain. Do not invent a generic idempotency header and assume every endpoint honours it. The service must actually define the mechanism and its scope.

The timeout article also distinguishes active waiting from elapsed wall time. A requested five-second signal is not a universal authority over a service's expiry or remote commit. A client can correctly stop waiting under its local policy while the service follows a different independently defined rule.

For the catalogue's harmless explanation lookup, a retry may be useful under a bounded policy. Even a read can consume resources and observe changed data. Choose retry behaviour from the operation and observed condition, rather than treating every catch as a reason to send the same request repeatedly until some green indicator appears.

Contents · Previous chapter · Next chapter

A readable unsuccessful response may contain a helpful diagnostic body. The client can interpret it under the documented error format while keeping it separate from successful catalogue data. A valid problem description is still a description of failure, not an explanation record for C17.

Limit what is retained and displayed. Error bodies can include HTML, private query fragments or infrastructure details. Showing their contents as executable markup or copying them into unrestricted logs can create a separate problem. A reader-facing message usually needs a bounded explanation and a safe reference rather than the entire raw body.

Do not assume the error body is JSON merely because successful responses are JSON. A proxy or authentication layer may return another media type. The client needs a controlled fallback for an unsupported diagnostic format instead of a second parser failure that erases the original status information.

The existing Problem Details guide develops machine-readable error categories. This article's narrower job is earlier in the JavaScript flow: determine whether a Response was obtained, whether its exposed status is acceptable and which body operation followed. These lessons connect without making error-format parsing a substitute for the fetch settlement boundary.

For a practical check, supply a 503 HTML diagnostic and confirm that the catalogue neither renders it as an explanation nor reports an empty successful record. Preserve the status category, handle the unsupported diagnostic form safely and tell the reader which useful action remains available under the product's actual policy.

Contents · Previous chapter · Next chapter

Even a complete, valid C17 response can arrive after the reader has selected C23. The fetch and parsing stages can all succeed while the old result no longer belongs in the current panel. This is a later application condition, not a reason to call the old HTTP response a failure.

Use two attempt labels in a paper trace. Attempt A requests C17. Attempt B becomes current and requests C23. B completes first and renders. A later returns valid C17 data. Before committing A, compare its attempt or selection identity with the panel's current state.

Under the stipulated current-selection policy, A is declined for display. The diagnostic record can still say its response was obtained, parsed and validated. This preserves useful evidence about network and data quality while correctly preventing an obsolete result from replacing the current explanation.

Capturing a button reference during an event listener does not by itself supply that permission. The object may remain alive while its role changes. The deferred-event lesson covers the input side; the saved-geometry lesson covers another observation that can become outdated between measurement and use.

The practical review question is where the final display condition is checked. If it exists only before fetch begins, it may be obsolete by the time the response arrives. If it is checked at the commit point under the application's chosen state model, the result can be assessed against the current selection rather than a historic assumption.

Contents · Previous chapter · Next chapter

The accompanying checks run an HTTP server bound to the local loopback interface, using an automatically allocated port. It serves controlled paths for a valid record, a readable 404 JSON error, malformed JSON under 200, a 204 response and a deliberately closed connection. No real catalogue or public service is called.

The 404 check verifies that fetch fulfils with status 404, ok false and a readable error body. The malformed-JSON check verifies that a 200 Response can be obtained before its json operation rejects. The 204 check verifies ok true and the absence of a usable JSON representation for an unconditional parse.

The valid-record check consumes a nonempty JSON body and confirms a second consumption rejects. A separate explicit status-policy operation throws for the 404, showing that this rejection comes from application logic. The closed-connection fixture exercises a fetch rejection without a usable Response in that controlled environment.

These checks were run with Node version 24.22.1. They verify the stated local runtime observations. They do not test browser CORS, opaque filtering, service-worker interception, mobile suspension or an external server's transaction history. Those claims would need different environments and evidence.

A useful test suite retains the fixture and its expected layer, not just a final pass count. When a future change fails, the author should be able to tell whether fetch settlement, status policy, body consumption, JSON syntax or catalogue validation changed. That distinction is the very skill the article is teaching.

Contents · Previous chapter · Next chapter

Now classify six invented attempts. A obtains 200 with valid C17 JSON. B obtains readable 404 with valid error JSON. C obtains 200 with malformed JSON. D obtains 204 with no body. E rejects before a readable Response is available. F obtains 200 with valid JSON for C23 instead of requested C17.

Five fetch promises fulfil: A, B, C, D and F. Four of those responses have ok true: A, C, D and F. Three supplied JSON texts parse in the stated fixtures: A, B and F. Only A supplies the expected explanation record under the lookup contract.

The counts are not a measured error rate. They are a deliberately constructed ledger that tests the boundaries. The fraction five out of six describes fetch fulfilment in this set, while one out of six describes accepted catalogue data. Calling both a success rate without naming the condition would conceal most of the lesson.

Change the operation for D from explanation lookup to a documented delete that legitimately returns 204. D can now satisfy that operation's response contract without a JSON body. Its fetch settlement and ok values have not changed. The task definition changed what further evidence was required.

Change F's requested identifier to C23. The same body can now pass the identity check, subject to its other validation and current display permission. These changed contexts show why the platform's boolean cannot encode every application requirement. Preserve the fixed API meanings, then apply the actual task's conditions explicitly.

Contents · Previous chapter · Next chapter

When the catalogue cannot show an explanation, say what the available evidence supports. A readable 404 can support a missing-resource classification under the endpoint contract. A body parse failure supports a format problem at that stage. No readable response leaves a broader set of possible causes.

For an engineering report, include the operation identity, fetch settlement, exposed response type and status where available, body operation and validation result. Include environment details for a reproducible failure while avoiding private payloads. A single screenshot of a catch message cannot reconstruct all those stages.

For a reader-facing message, translate the relevant outcome into a useful next step. A corrected record choice, a later retry or a service-support route may fit different conditions. Do not make the person diagnose HTTP internals merely to understand whether their explanation is available.

When reviewing code, trace where each promise is created and where each possible throw occurs. Confirm that a fallback does not silently turn failure into a false empty result. Confirm that current display permission is checked after accepted data is ready. Then test a changed method, body contract or response type.

The transferable principle is to keep a received response separate from an accepted result. Once fetch settlement, HTTP status, body interpretation and application acceptance have their own names, seemingly contradictory logs become an understandable sequence. The client can recover from the actual condition instead of treating every error word as the same event.

Contents · Previous chapter · Return to Websites