WEB / WEB-10.04

Resource, script, and request loading

Download, execution, and application outcomes occur at different points. Separate parser discovery, script scheduling, and Fetch/XHR completion using a loading ledger.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

defer A→B

A/B discovered
The document parser has discovered deferred A/B scripts; initiated fetches and origin receipt are supplied initial conditions. This slice follows B/A response arrivals, with neither script evaluated yet.
Document / Duru
A/B declared; parser running
Resource loader
A/B fetch initiated
Origin / Atlas
A/B requests supplied arrived
Execution / API state
Executed=[]
B resource arrived
In the selected fixture B arrives at the loader first; parsing completion is not yet supplied.
Document / Duru
Parser running
Resource loader
B ready; A pending
Origin / Atlas
B200 complete; A pending
Execution / API state
Executed=[]
B execution decision
defer B waits for A/parsing; the async branch executes B when ready.
Document / Duru
Parser running
Resource loader
B ready; A pending
Origin / Atlas
A response pending
Execution / API state
Executed=[]
Parsing complete
Parsing completes; with A still pending, the defer execution queue must still wait.
Document / Duru
Parser complete
Resource loader
B ready; A pending
Origin / Atlas
A response pending
Execution / API state
Executed=[]
A resource arrived
A now reaches the loader, completing the selected resource-ready order as B/A.
Document / Duru
Parser complete
Resource loader
A/B ready
Origin / Atlas
A200/B200 complete
Execution / API state
Executed=[]
Local evaluation
defer evaluates its ordered queue as A then B; local execution is not another network response.
Document / Duru
Parser complete
Resource loader
A/B ready
Origin / Atlas
Exchange complete
Execution / API state
Executed=[A,B]
Preserve event boundary
Duru reads execution results; image loading and all application async jobs are not measured by this list.
Document / Duru
DOM/execution observation complete
Resource loader
A/B ready
Origin / Atlas
Exchange complete
Execution / API state
Executed=[A,B]

async B→A

A/B discovered
The parser has discovered async A/B scripts; initiated fetches and origin receipt are supplied initially. B/A readiness is this example’s selected order; declaration order provides no evaluation guarantee.
Document / Duru
A/B declared; parser running
Resource loader
A/B fetch initiated
Origin / Atlas
A/B requests supplied arrived
Execution / API state
Executed=[]
B resource arrived
In the selected fixture B arrives at the loader first; parsing completion is not yet supplied.
Document / Duru
Parser running
Resource loader
B ready; A pending
Origin / Atlas
B200 complete; A pending
Execution / API state
Executed=[]
B execution decision
The async branch executes B when ready without claiming declaration-order guarantees.
Document / Duru
Parser running
Resource loader
B ready; A pending
Origin / Atlas
A response pending
Execution / API state
Executed=[B]
Parsing complete
Document parsing completes. B has already executed in this async branch while A’s response is still pending. This step runs no defer queue and does not assume that A evaluated earlier.
Document / Duru
Parser complete
Resource loader
B ready; A pending
Origin / Atlas
A response pending
Execution / API state
Executed=[B]
A resource arrived
A now reaches the loader, completing the selected resource-ready order as B/A.
Document / Duru
Parser complete
Resource loader
A/B ready
Origin / Atlas
A200/B200 complete
Execution / API state
Executed=[B]
Local evaluation
async A now evaluates, completing selected B/A execution; other orders remain possible.
Document / Duru
Parser complete
Resource loader
A/B ready
Origin / Atlas
Exchange complete
Execution / API state
Executed=[B,A]
Preserve event boundary
Duru reads execution results; image loading and all application async jobs are not measured by this list.
Document / Duru
DOM/execution observation complete
Resource loader
A/B ready
Origin / Atlas
Exchange complete
Execution / API state
Executed=[B,A]

404 completion

Fetch GET ready
Duru requests a harmless missing note; initially no Response or consumed body exists.
Document / Duru
GET /notes/missing ready
Resource loader
Request pending
Origin / Atlas
No request yet
Execution / API state
Promise pending; body absent
Request arrived
The GET reaches the origin for a public missing-resource result.
Document / Duru
Waiting response
Resource loader
Request dispatched
Origin / Atlas
GET received; missing note
Execution / API state
Promise pending; body absent
404 prepared
The origin prepares 404 Not found as a normal HTTP response rather than a network error.
Document / Duru
Waiting response
Resource loader
Waiting headers
Origin / Atlas
404 ready; Not found
Execution / API state
Promise pending; body absent
404 headers arrived
The loader receives status and headers; a Response can be exposed while body consumption remains separate.
Document / Duru
Response available
Resource loader
404 headers received
Origin / Atlas
404 body delivery pending
Execution / API state
Promise fulfilled; status404; ok=false
Content completed
Not found content reaches the loader so the separate body-read operation can complete.
Document / Duru
Response available
Resource loader
404 body complete
Origin / Atlas
404 fully delivered
Execution / API state
Promise fulfilled; body read pending
Local outcome check
The client consumes text and rejects HTTP success on status404; XHR load also requires a status check.
Document / Duru
Show missing note outcome
Resource loader
404 body complete
Origin / Atlas
Exchange complete
Execution / API state
Body=Not found; accepted=false

Abort after headers

Cancellable GET
Duru starts a public slow-note GET with a default AbortController signal.
Document / Duru
GET /notes/slow ready
Resource loader
Request pending
Origin / Atlas
No request yet
Execution / API state
Promise pending; body absent
GET arrived
The origin receives GET, already limiting any claim that the server never processed it.
Document / Duru
Waiting response
Resource loader
Request dispatched
Origin / Atlas
GET received; benign read
Execution / API state
Promise pending; body absent
200 headers arrived
200 status and headers reach the loader while the selected body remains incomplete.
Document / Duru
Response available
Resource loader
200 headers; body incomplete
Origin / Atlas
200 headers sent; body pending
Execution / API state
Promise fulfilled; body incomplete
Local abort
Duru calls abort(); the model invents neither a cancellation wire packet nor a server rollback message.
Document / Duru
Abort called
Resource loader
Client operation cancelled
Origin / Atlas
GET observed; rollback not proven
Execution / API state
Response exists; body unavailable
Body read rejects
The incomplete body text() read rejects with default AbortError; the fulfilled Response is not undone.
Document / Duru
Abort outcome shown
Resource loader
Client operation cancelled
Origin / Atlas
GET observed; rollback not proven
Execution / API state
bodyRead=AbortError; server outcome bounded

ACTORS · STATE · DATA FLOW

Resource discovery is not execution

Atlas HTML exposes CSS, image, and script URLs; JavaScript can also start Fetch or XMLHttpRequest. Browser scheduling, cache lookup, network transfer, and decode/execute are separate jobs. A Network-table row does not prove complete content or script execution. Preload/scanning can discover resources early, so request order is not simply the order in which the DOM parser advances.

An external parser-inserted classic script without async/defer blocks parsing until fetching/evaluation complete, not every browser activity. An inline classic script has no external download. The fixture selects normal JavaScript MIME types and same-origin resources; stylesheet blocking, policy refusal, and force-async rules for dynamic insertion are outside its scope.

Download order and execution order differ

Suppose two external classic scripts appear as defer A followed by B. Fetching can proceed alongside parsing; even if B becomes ready first, this parser-inserted deferred pair executes A then B after parsing finishes. DOMContentLoaded waits for this deferred execution. It does not guarantee all images or every application async task have finished.

An async classic pair has no declaration-order guarantee; scripts can execute when ready, potentially before parsing completes. The artifact selects B-ready-before-A, not a rule that async always reverses order. Binding dependent A/B operations to this unordered contract can cause availability or state errors.

A default type=module script is deferred until after parsing and loads its static dependency graph; adding defer has no further effect. An async module can evaluate earlier when its graph is ready. Module evaluation has a different scope contract from classic global scripts. Top-level await adds async-evaluation nuances; this fixture uses a small graph without await and does not claim DOMContentLoaded finishes every async module task.

Response, body, and status are separate gates

Fetch can fulfill with a Response once status and headers are available while content still streams. response.text()/json() is separate async consumption. A disturbed or locked body limits reuse; do not assume the same body can be read twice. JSON parse failure also differs from HTTP-status failure. The GET fixture has no request body; Fetch does not accept a non-null GET/HEAD body.

404 normally does not reject Fetch: it produces status404 and ok=false. XHR load also represents the transfer-completion path, requiring a separate status check; 404 can produce load. DONE alone establishes neither HTTP nor business success. XHR error/abort and Fetch rejection are different API surfaces rather than one success boolean.

AbortController describes cancellation of the client operation. Aborting after headers does not undo a fulfilled Fetch Promise; reading content can reject with AbortError. If the request reached the server, cancellation proves neither that it was unprocessed nor that it rolled back. The native example is a benign GET; WEB-07.02 separately covers action retry semantics.

Request.cache participates in browser HTTP-cache selection. default uses normal eligibility/freshness; no-cache asks for validation even with an eligible entry, while no-store bypasses this cache and does not write the response into it. This API setting does not clear every shared cache or Service Worker Cache API. Read it with the detailed HTTP rules in WEB-09.02–03.

Read every scenario without motion

Async dependency

Declaration and readiness became separate orders
Scripts are declared A,B but become ready B,A. Parser-inserted external classics and no CSS blocking are supplied. B being downloaded does not imply that A initialized its required state.
Resource/API record
Declared A,B / ready B,A
Dependency/completion gate
Gate pending
Application state
No outcome
Async execution did not guarantee the dependency
Selected async execution is B,A and asyncOrderGuaranteed is false. If A must initialize required state first, declaration order is the wrong acceptance predicate. Explicit dependency or ordered execution is required.
Resource/API record
Declared A,B / ready B,A
Dependency/completion gate
Selected async B,A / order not guaranteed
Application state
No outcome
A loaded label was not initialized state
Resource readiness, script evaluation and initialized application state are different milestones. Wrong order may leave an undefined dependency or partial UI. The harmless fixture only records names and performs no protected action.
Resource/API record
Declared A,B / ready B,A
Dependency/completion gate
Selected async B,A / order not guaranteed
Application state
Ready ≠ evaluated or application initialized
Defer provided an ordinary comparison branch
deferredExecution is A,B before DOMContentLoaded. Here defer provides ordered execution after parsing. That loading contract does not solve authentication, schema or server-side business gates.
Resource/API record
Defer A,B / before DOMContentLoaded
Dependency/completion gate
Selected async B,A / order not guaranteed
Application state
Ready ≠ evaluated or application initialized
The module graph retained its qualification
main.mjs depends on helper.mjs, with defaultDeferred true and deferAttributeAddsEffect false. Absence of top-level await is supplied. This graph’s order is not generalized to every async module/TLA scenario.
Resource/API record
Defer A,B / before DOMContentLoaded
Dependency/completion gate
Explicit helper.mjs→main.mjs / no TLA supplied
Application state
Ready ≠ evaluated or application initialized
Control remained at the right dependency boundary
Control explicitly relates source loading to initialization of required state. Exact latency and all module-graph behavior are unmeasured. Ordered local evaluation is not broader business success.
Resource/API record
Defer A,B / before DOMContentLoaded
Dependency/completion gate
Explicit helper.mjs→main.mjs / no TLA supplied
Application state
Explicit initialization dependency required

HTTP/body gates

The 404 was recorded as a fulfilled Response
fetch404 produces fulfilled-response with status 404, ok false and body Not found. XHR reports load and readyState 4 with the same 404. API completion is not HTTP success or successful action.
Resource/API record
Fetch fulfilled / XHR load / HTTP404
Dependency/completion gate
Gate pending
Application state
No outcome
The status gate withheld successful-action interpretation
acceptedAsHttpSuccess is false. The client separately checks status range and expected content contracts. An ordinary 404 is neither attack attribution nor proof that the server never received the request.
Resource/API record
Fetch fulfilled / XHR load / HTTP404
Dependency/completion gate
404 not accepted as HTTP success
Application state
No outcome
The UI did not overinterpret completion
Even complete-text consumption of a 404 does not provide the application’s expected successful content. Having a Response and validating parsed data are separate gates. Status and content outcomes are not reduced to one done label.
Resource/API record
Fetch fulfilled / XHR load / HTTP404
Dependency/completion gate
404 not accepted as HTTP success
Application state
Body read complete / business success not inferred
Abort did not undo header receipt
abortAfterHeaders supplies a fulfilled Response with status 200 but bodyCompleteBeforeAbort false. Default abort reason and bodyReadOutcome are AbortError. Headers can be received while the body remains incomplete.
Resource/API record
Response200 exists / body read AbortError
Dependency/completion gate
404 not accepted as HTTP success
Application state
Body read complete / business success not inferred
Cancellation was not proof of server rollback
requestReachedOriginSupplied is true and serverNeverProcessedProven false. Abort may stop client consumption without proving the server never saw the request or rolled back an action. Retrying needs separate product reconciliation.
Resource/API record
Response200 exists / body read AbortError
Dependency/completion gate
Client abort / server processing not disproven
Application state
Body read complete / business success not inferred
The failure boundary retained public-GET scope
This public-GET ledger distinguishes status, Response and body state without measuring mutating transactions, current authorization or server rollback. Correct UI handling explicitly states which completion did not occur.
Resource/API record
Response200 exists / body read AbortError
Dependency/completion gate
Client abort / server processing not disproven
Application state
Status/body/cancellation distinct / mutation unmeasured

ASSUMPTION · BOUNDARY · CONTROL

A loaded resource is not a trusted outcome

Loading order is a dependency contract. If A must initialize state before B, trusting declaration order for an async pair is an incorrect acceptance rule. Effects include missing dependencies, incomplete DOM updates, or partial UI state. A downloaded-script observation does not prove initialization finished.

Express dependencies through a module graph or appropriate ordered execution and separately identify awaited async completion. defer provides post-parsing execution, not backend policy, identity, or business validation. A loading event must not substitute for an application invariant. The scene scripts only add harmless names to an ordering ledger.

Do not overinterpret cancellation or completion

Treating a fulfilled 404 as a successful action leads to incorrect UI decisions. Treating an aborted request as unseen by the server also exceeds the evidence. The failure condition conflates status, body state, and client outcome; impact depends on the operation.

Evaluate status range, expected format, complete consumption, and the action contract independently. Received headers can remain available after abort while content is unavailable. When server outcome is unknown, retry depends on method semantics and product reconciliation. This public GET fixture tests no authorization or mutating transaction.

Read every scenario without motion

Loading order

Downloaded B was not evaluation evidence
Loading producers differ: parser declaration, loader readiness and script evaluation. API records separate Fetch/XHR status from body-reader completion. The selector reads authored status/acceptedAsHttpSuccess rows only; it is neither a real browser log nor server-commit measurement. Ready B,A and declaration A,B are separate arrays. Executed lists may remain empty at B-ready. Download supplies source bytes; evaluation dependencies and parser context remain other predicates.
Loading observations
Declared A,B / ready B,A / evaluation separate
Order/body comparison
Gate pending
Evidence verdict
No outcome
Ordered and async results used the same input context
Defer yields A,B while selected async yields B,A. Async B,A is possible but not every possible outcome. A cache path may affect loading; executed source is not called a network capture without observing bytes.
Loading observations
Declared A,B / ready B,A / evaluation separate
Order/body comparison
Defer A,B / selected async B,A
Evidence verdict
No outcome
Module qualifications retained dependency names
The helper.mjs/main.mjs graph is deferred by default; defer adds no effect. Absence of top-level await and ordinary MIME are supplied. Without retaining these qualifiers, a readiness timestamp is not a broad guarantee.
Loading observations
Module graph qualified / no TLA
Order/body comparison
Defer A,B / selected async B,A
Evidence verdict
No outcome
Lifecycle events were not treated as one timestamp
Parser completion, DOMContentLoaded and window load are distinct causal milestones. The fixture supplies deferBeforeDOMContentLoaded true without exact latency benchmarking. Evaluation and visible UI outcomes need separate correlation.
Loading observations
Module graph qualified / no TLA
Order/body comparison
Defer before DCL / exact latency unknown
Evidence verdict
No outcome
Dependency verdicts were not browser-wide generalizations
Order can be explained within this selected context. CORS/policy refusal, arbitrary modules and device timing are unmeasured. One load event does not prove correct order without source attributes and the dependency graph.
Loading observations
Module graph qualified / no TLA
Order/body comparison
Defer before DCL / exact latency unknown
Evidence verdict
Selected order known / broader loader unmeasured
Regression checked two orders with required state
Regression separately rechecks declaration, readiness, evaluation and required initialization state. Sensitive source or full application data is unnecessary. Ordinary async reordering is handled explicitly when a dependency exists.
Loading observations
Module graph qualified / no TLA
Order/body comparison
Defer before DCL / exact latency unknown
Evidence verdict
Recheck attributes/readiness/evaluation/initialization

Partial body

The partial response retained two milestones
Loading producers differ: parser declaration, loader readiness and script evaluation. API records separate Fetch/XHR status from body-reader completion. The selector reads authored status/acceptedAsHttpSuccess rows only; it is neither a real browser log nor server-commit measurement. After headers, status 200 and a fulfilled Response exist without a complete body. AbortError belongs to content reading. HTTP status can be in a successful range while body consumption fails.
Loading observations
Headers200 / Response fulfilled / body incomplete
Order/body comparison
Gate pending
Evidence verdict
No outcome
Body outcomes were separated from another success field
Body-read AbortError does not erase the existing Response, whose ok may be true. Review records body ownership/consumption separately. Absent content is not parsed as a JSON document; a second read also needs ownership review.
Loading observations
Headers200 / Response fulfilled / body incomplete
Order/body comparison
Response retained / body read failed separately
Evidence verdict
No outcome
The status oracle retained a separate positive control
Normal XML reports 404 with acceptedAsHttpSuccess false and count zero; positive XML reports true and count one. The oracle selects promotion of API completion into HTTP success, not a real browser-event log.
Loading observations
404 acceptance oracle normal0 / positive1
Order/body comparison
Response retained / body read failed separately
Evidence verdict
No outcome
A missing content event was not ordinary completion
If an alternative trace lacks consumption outcomes, a fulfilled Response does not prove complete body receipt. The normal complete-text result cannot replace a missing event. Interruptions, aborts and logging gaps need different causal evidence.
Loading observations
404 acceptance oracle normal0 / positive1
Order/body comparison
Consumption coverage missing / do not infer complete
Evidence verdict
No outcome
The server-state verdict remained unknown
A client-abort record alone does not explain server processing. The fixture supplies origin reachability without measuring transactions or rollback. Server outcomes may remain UNKNOWN; retrying does not automatically close the gap.
Loading observations
404 acceptance oracle normal0 / positive1
Order/body comparison
Consumption coverage missing / do not infer complete
Evidence verdict
UNKNOWN: unobserved server processing/rollback
New evidence retained status/body/action scope
Review needs status, content type, consumption outcome and, when required, scoped server results without credentials or full private bodies. HTTP-cache choices are recorded separately from Cache API and proxy policy.
Loading observations
404 acceptance oracle normal0 / positive1
Order/body comparison
Consumption coverage missing / do not infer complete
Evidence verdict
Needed: response/body outcome plus scoped server result

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Keep two orders in the loading ledger

Loading producers differ: parser declaration, loader readiness and script evaluation. API records separate Fetch/XHR status from body-reader completion. The selector reads authored status/acceptedAsHttpSuccess rows only; it is neither a real browser log nor server-commit measurement. The artifact separately records declarationOrder A/B, readyOrder B/A, and deferredExecution A/B. Identify the attribute preserving execution order and verify the executed list remains empty when B downloads. Selected B/A execution is possible in the async branch without exhausting normal outcomes.

Do not assign one timestamp to parser completion, DOMContentLoaded, and window load. A native fixture can measure selected causal-event order, while an authored order is not a latency benchmark. Keep module dependencies distinct. Loading can use a cache path for the same URL, so network-byte observations and executed source are not interchangeable.

If B depends on data prepared by A, declaring two parser-inserted external classic scripts with async does not preserve that dependency. Use defer in declaration order or express the dependency with an import in the module graph. Here deferred evaluation remains A/B even when B becomes ready first. async for an independent script is a different decision; HTML declaration order alone cannot make it appropriate for dependent scripts.

Describe API outcomes in three fields

Record fulfilled-response, status404/okfalse, and body-consumption outcome separately for Fetch. XHR combines event=load with status404. After-headers abort has a Response but bodyRead=AbortError. The selector detects status>=400 with acceptedAsHttpSuccess=true; distinguish normal0, positive1, and missing0 evidence.

Keep manual inspection read-only on the benign GET target. Consider consumption ownership before attempting to read content again and do not treat absent content as JSON. For a cache path, record Request.cache alongside response policy. A Console done message cannot replace these fields; application logging needs context.

A Fetch consumer should decide from status/ok, complete the required body read, and advance the UI with new content only after those operations succeed. This fulfilled 404 is not HTTP success. An after-headers-aborted 200 also supplies no successfully read content: handle the body reader’s AbortError without creating a successful-loading state. Compare normal text receipt and these two branches separately; client cancellation does not prove the server performed no work.

NOW APPLY IT TO THE CASE

What separate decisions are needed for script order, fulfilled Responses and cancellation?

B may be ready first despite A,B declaration: defer retains A,B while the selected async branch evaluates B,A. A public missing note may yield a fulfilled 404 Response. Abort after headers retains the Response but causes body-read AbortError.

Order response receipt, parsing, callbacks and visible DOM outcome in the case. Try explaining the retained old title through this lesson’s browser-state distinctions.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Loading-order and API-outcome ledger

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "scriptContext": {
    "parserInsertedExternalClassic": true,
    "cssBlockingAbsentSupplied": true,
    "normalSameOriginMimeSupplied": true,
    "moduleTopLevelAwaitAbsentSupplied": true
  },
  "scriptPair": {
    "declarationOrder": [
      "A",
      "B"
    ],
    "readyOrderSupplied": [
      "B",
      "A"
    ],
    "deferredExecution": [
      "A",
      "B"
    ],
    "asyncSelectedExecution": [
      "B",
      "A"
    ],
    "asyncOrderGuaranteed": false,
    "deferBeforeDOMContentLoaded": true
  },
  "module": {
    "dependency": "helper.mjs",
    "entry": "main.mjs",
    "defaultDeferred": true,
    "deferAttributeAddsEffect": false,
    "graphWithoutTopLevelAwait": true
  },
  "fetch404": {
    "path": "/notes/missing",
    "promiseOutcome": "fulfilled-response",
    "status": 404,
    "ok": false,
    "body": "Not found",
    "bodyReadOutcome": "complete-text",
    "acceptedAsHttpSuccess": false
  },
  "xhr404": {
    "path": "/notes/missing",
    "event": "load",
    "readyState": 4,
    "status": 404,
    "body": "Not found",
    "acceptedAsHttpSuccess": false
  },
  "abortAfterHeaders": {
    "path": "/notes/slow",
    "requestReachedOriginSupplied": true,
    "promiseOutcome": "fulfilled-response",
    "status": 200,
    "bodyCompleteBeforeAbort": false,
    "defaultAbortReason": "AbortError",
    "bodyReadOutcome": "AbortError",
    "serverNeverProcessedProven": false
  },
  "cacheChoices": [
    {
      "value": "default",
      "selection": "normal HTTP cache eligibility/freshness"
    },
    {
      "value": "no-cache",
      "selection": "matching response requires validation"
    },
    {
      "value": "no-store",
      "selection": "bypass and do not write browser HTTP cache"
    }
  ],
  "selector": {
    "language": "XPath",
    "xml": "<observations><result status=\"404\" acceptedAsHttpSuccess=\"false\"/></observations>",
    "xpath": "count(/observations/result[number(@status)>=400 and @acceptedAsHttpSuccess=\"true\"])",
    "expected": 0,
    "positiveFixtureXml": "<observations><result status=\"404\" acceptedAsHttpSuccess=\"true\"/></observations>",
    "positiveExpected": 1,
    "scope": "Only authored protocol-decision observations, not product log field names or a live HTTP capture.",
    "missingFieldBehavior": "Missing observation is insufficient evidence; zero matches is not proof of correct runtime behavior."
  }
}

readyOrder / execution: Resource availability and JavaScript evaluation are separate orders.
fetch404 / xhr404: API completion differs from HTTP success; load/fulfilled 404 is possible.
abortAfterHeaders: Header arrival remains observed; incomplete content reading can abort.
cacheChoices: Browser HTTP-cache choice, not Cache API or every proxy policy.

Resource-ready order, parser context, and full/partial response events are supplied. No exact latency, general module/TLA graph, CORS/policy refusal, or server rollback is measured.

Two reality checks

defer scripts download in declaration order; async always reverses order.

defer preserves execution order while readiness can differ. async has no order guarantee; B/A is a selected fixture.

Fetch fulfillment/XHR load means HTTP success; abort rolls back the server.

404 can use the normal completion path. Abort cancels the client operation without proving no server processing or rollback.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

B is ready first; A is declared first. What is the selected defer execution order?

A, B; declaration order is preserved.
B, A; defer always follows download-completion order.

Read the explained answer

A, B; declaration order is preserved. — In the selected context, defer provides beforeDOMContentLoaded ordered execution; readyOrder does not reverse it.

How does abort affect body reading after receiving 200 headers?

Selected lesson artifact fields; teaching example

abortAfterHeaders: {"path":"/notes/slow","requestReachedOriginSupplied":true,"promiseOutcome":"fulfilled-response","status":200,"bodyCompleteBeforeAbort":false,"defaultAbortReason":"AbortError","bodyReadOutcome":"AbortError","serverNeverProcessedProven":false}

Abort proves the server never received the request.
The Response may already be fulfilled; incomplete body reading produces AbortError.

Read the explained answer

The Response may already be fulfilled; incomplete body reading produces AbortError. — Selected promiseOutcome is fulfilled-response and bodyReadOutcome is AbortError; origin processing may already have occurred.

Why should Fetch 404 and XHR 404 not be combined as network failures? Also distinguish cache no-cache/no-store choices.

Read the explained answer

Fetch 404 completes with a fulfilled Response+ok=false, while XHR 404 completes with load/readyState=4; neither is accepted as HTTP success. no-cache requires validation of a matching cached response; no-store bypasses the selected browser HTTP cache and performs no new write. Neither guarantees application-cache behavior or business rollback.

□ I did not count API completion as HTTP success.

□ I distinguished validation from cache-storage prohibition.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

WHATWG HTML — script element4.12.1 The script element · 4.12.1.1 Processing model
WHATWG — Fetch Standard1 Preface · 4.6 HTTP-network-or-cache fetch · 5.3 Body mixin · 5.6 Fetch methods
WHATWG — XMLHttpRequest Standard3.5.6 The send() method · 3.5.7 The abort() method · 3.6.2 The status getter
MDN — script elementasync and defer · Notes
MDN — Using the Fetch APICanceling a request · Handling the response · Checking response status · Reading the response body
MDN — Request: cache propertyValue

YOUR NOTES / THIS BROWSER

Resource, script, and request loading

1. Core · Mechanism

defer A→B

async B→A

404 completion

Abort after headers

Resource discovery is not execution

Download order and execution order differ

Response, body, and status are separate gates

2. Red · Trust & Impact

Async dependency

HTTP/body gates

A loaded resource is not a trusted outcome

Do not overinterpret cancellation or completion

3. Blue · Secure development & defense

Loading order

Partial body

Keep two orders in the loading ledger

Describe API outcomes in three fields

What separate decisions are needed for script order, fulfilled Responses and cancellation?

Two reality checks

B is ready first; A is declared first. What is the selected defer execution order?

How does abort affect body reading after receiving 200 headers?

Why should Fetch 404 and XHR 404 not be combined as network failures? Also distinguish cache no-cache/no-store choices.

Sources and scope