WEB / WEB-07.01

HTTP request and response anatomy

A browser URL, transmitted request, and received response are different objects. Separate HTTP control data, headers, and content.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

HTTP/1.1 pair

Browser URL
The fragment remains client-side; no request has been constructed.
Browser / Duru
URL and #details
Atlas Application
No request
Resource / local state
Atlas note: available
Construct the request
Select path/query without the fragment. Use HTTP/1.1 origin-form.
Browser / Duru
GET target ready; #details local; awaiting response
Atlas Application
No request
Resource / local state
Atlas note: available
Request arrived at the Application
The Application received the GET target and header context; no response has been constructed.
Browser / Duru
GET target ready; #details local; awaiting response
Atlas Application
GET target received
Resource / local state
Atlas note: available
Select the representation
Local routing selects Atlas note; no external database wire is assumed.
Browser / Duru
Awaiting response
Atlas Application
Selected representation: Atlas note
Resource / local state
Atlas note: available
Response prepared
200, media metadata, and 10-byte content are ready; the browser has not received them.
Browser / Duru
Awaiting response
Atlas Application
200 ready; 10 bytes
Resource / local state
Atlas note: available
Response arrived at the Browser
200 and Atlas note are now at the browser; semantic-field notation is not a frame dump.
Browser / Duru
200 received; Atlas note
Atlas Application
200 ready; 10 bytes
Resource / local state
Atlas note: available
Interpret in GET context
Interpret content as the target representation; fragment selection remains client-side.
Browser / Duru
GET representation; #details local
Atlas Application
200 ready; 10 bytes
Resource / local state
Atlas note: available

HTTP/2–3 semantic view

Browser URL
The fragment remains client-side; no request has been constructed.
Browser / Duru
URL and #details
Atlas Application
No request
Resource / local state
Atlas note: available
Construct the request
Select path/query without the fragment. Prepare pseudo-header projection.
Browser / Duru
:method GET, :path ready; #details local; awaiting response
Atlas Application
No request
Resource / local state
Atlas note: available
Request arrived at the Application
The Application received the GET target and header context; no response has been constructed.
Browser / Duru
:method GET, :path ready; #details local; awaiting response
Atlas Application
:method GET and :path received
Resource / local state
Atlas note: available
Select the representation
Local routing selects Atlas note; no external database wire is assumed.
Browser / Duru
Awaiting response
Atlas Application
Selected representation: Atlas note
Resource / local state
Atlas note: available
Response prepared
200, media metadata, and 10-byte content are ready; the browser has not received them.
Browser / Duru
Awaiting response
Atlas Application
:status 200 ready; content 10 bytes
Resource / local state
Atlas note: available
Response arrived at the Browser
200 and Atlas note are now at the browser; semantic-field notation is not a frame dump.
Browser / Duru
:status 200 received; Atlas note
Atlas Application
:status 200 ready; content 10 bytes
Resource / local state
Atlas note: available
Interpret in GET context
Interpret content as the target representation; fragment selection remains client-side.
Browser / Duru
GET representation; #details local
Atlas Application
:status 200 ready; content 10 bytes
Resource / local state
Atlas note: available

Response did not arrive

Browser URL
The fragment remains client-side; no request has been constructed.
Browser / Duru
URL and #details
Atlas Application
No request
Resource / local state
Atlas note: available
Construct the request
Select path/query without the fragment. Use HTTP/1.1 origin-form.
Browser / Duru
GET target ready; #details local; awaiting response
Atlas Application
No request
Resource / local state
Atlas note: available
Request arrived at the Application
The Application received the GET target and header context; no response has been constructed.
Browser / Duru
GET target ready; #details local; awaiting response
Atlas Application
GET target received
Resource / local state
Atlas note: available
Select the representation
Local routing selects Atlas note; no external database wire is assumed.
Browser / Duru
Awaiting response
Atlas Application
Selected representation: Atlas note
Resource / local state
Atlas note: available
Response prepared
200, media metadata, and 10-byte content are ready; the browser has not received them.
Browser / Duru
Awaiting response
Atlas Application
200 ready; 10 bytes
Resource / local state
Atlas note: available
No response observed
This branch supplies non-arrival of the entire response; server status remains unknown to the browser.
Browser / Duru
Status unknown; no response
Atlas Application
200 ready; 10 bytes
Resource / local state
Atlas note: available

ACTORS · STATE · DATA FLOW

What agreement does HTTP establish?

Duru opens a note in Atlas library. A browser request communicates the desired operation on a resource; the Atlas Application interprets it and returns a response. HTTP is an application-level protocol. DNS, connections, and TLS support transport without independently deciding a note’s business meaning or Duru’s permissions.

HTTP/1.1, HTTP/2, and HTTP/3 differ in message framing and transport details while sharing much of the semantics of methods, statuses, fields, and representations. The line-oriented text here is HTTP/1.1 notation. Similar lines displayed by DevTools do not mean HTTP/2 transmits a text start-line.

Request: intent, target, and context

The example request-line is GET /notes/atlas-1?view=summary HTTP/1.1. GET expresses the operation, path/query identifies the request target, and HTTP/1.1 identifies syntax version. Origin-form for a direct origin request carries the path and optional query. Host: library.atlas.example supplies authority information; connection context contributes the scheme.

The browser URL’s #details fragment is excluded from this request target. A fragment can select a portion of a representation on the client; it is not another query value sent to the server. Proxy absolute-form, CONNECT authority-form, and server-wide OPTIONS asterisk-form serve different contexts; a full URL is not placed on every request-line.

Headers provide additional context. Accept: text/plain expresses a client preference rather than guaranteeing the server result. A blank line ends the header section. This GET fixture has no content, which does not mean every request lacks a body. WEB-07.02 develops method/body semantics; WEB-07.03 covers framing and media types.

Response: decision, metadata, and content

In the HTTP/1.1 200 OK status-line, the numeric status supplies semantics. The reason phrase is descriptive and should not serve as an application success key. Response headers supply metadata such as Content-Type and Content-Length. After the blank line, Atlas note is this fixture’s content: being ASCII, its 10 characters also occupy 10 bytes.

A client interprets a response in the context of its request. A GET 200 can carry the target representation; a POST 200 can carry action results. A HEAD response can resemble the beginning of GET without transferring representation data. Interpreting a message is more than treating everything after a blank line as JSON.

The same semantic request is projected for HTTP/2–3 using :method, :scheme, :authority, and :path, while :status describes response control data. Ordinary headers and content remain separate. This projection is not a frame dump: HPACK/QPACK, stream IDs, and binary framing are omitted.

Prepared at the server does not mean received by the browser

The scene first shows the browser URL, then the request received by the Application, and finally the response received by the browser. Local route selection is not a network packet. Resource state is an in-process instructional fixture rather than an assumed database call.

In the response-loss branch the Application prepared 200, but the browser received no response. This observation cannot prove that server processing did not occur or reveal its status. The model assumes no part of the response arrived; it does not measure partial bodies, timeout durations, or transport algorithms. Correlation across both ends explains more than a single sent record.

Read every scenario without motion

Routing scope

Client selection was read in its scope
The browser URL contains notes/atlas-1?view=summary#details; requestTarget excludes the fragment. Host library.atlas.example and Accept text/plain are client context, not a verified account or object permission.
Protocol evidence
Target path/query / no fragment
Application trust gate
No trust gate
Access/format review
No access result
Routing was not substituted for identity
The application routes using canonical target/authority fields; protected resources separately require trusted permission decisions. Atlas text in a Host or URL does not open that gate.
Protocol evidence
Target path/query / no fragment
Application trust gate
Routing fields ≠ permission
Access/format review
No access result
Display notation is not protocol encoding
The HTTP/1.1 example separates GET start-line, headers, CRLF CRLF and Atlas note content. Other versions do not carry those semantics with the same start-line bytes.
Protocol evidence
H1 text / CRLF boundaries
Application trust gate
Routing fields ≠ permission
Access/format review
No access result
Content completeness is a separate condition
Headers being available do not show that Atlas note content is complete. bodyOctets=10 belongs to this complete supplied pair; framing and receipt remain independent of display notation.
Protocol evidence
H1 text / CRLF boundaries
Application trust gate
Headers / complete body separate
Access/format review
No access result
200 does not pass every gate
Response 200 is HTTP/application status information, not proof of correct access control, identity or a rendered view. Resource delivery and scope need separate review.
Protocol evidence
H1 text / CRLF boundaries
Application trust gate
Headers / complete body separate
Access/format review
Status200 / permission unknown
The boundary claim stayed narrow
Client routing is separated from trusted resource authority. The inert message pair is not sent to an external target; complete notation proves no actual enforcement.
Protocol evidence
H1 text / CRLF boundaries
Application trust gate
Headers / complete body separate
Access/format review
Routing scope known / authz separate

Display scope

Client selection was read in its scope
The browser URL contains notes/atlas-1?view=summary#details; requestTarget excludes the fragment. Host library.atlas.example and Accept text/plain are client context, not a verified account or object permission.
Protocol evidence
Target path/query / no fragment
Application trust gate
No trust gate
Access/format review
No access result
Routing was not substituted for identity
The application routes using canonical target/authority fields; protected resources separately require trusted permission decisions. Atlas text in a Host or URL does not open that gate.
Protocol evidence
Target path/query / no fragment
Application trust gate
Routing fields ≠ permission
Access/format review
No access result
Display notation is not protocol encoding
semanticProjection includes :method/:path/:status; it is not HTTP/2 and HTTP/3 encoded frames. A display converted to 200/header lines does not prove HTTP/1.1 wire encoding.
Protocol evidence
Semantic fields / not encoded frames
Application trust gate
Routing fields ≠ permission
Access/format review
No access result
Content completeness is a separate condition
Headers being available do not show that Atlas note content is complete. bodyOctets=10 belongs to this complete supplied pair; framing and receipt remain independent of display notation.
Protocol evidence
Semantic fields / not encoded frames
Application trust gate
Headers / complete body separate
Access/format review
No access result
200 does not pass every gate
Response 200 is HTTP/application status information, not proof of correct access control, identity or a rendered view. Resource delivery and scope need separate review.
Protocol evidence
Semantic fields / not encoded frames
Application trust gate
Headers / complete body separate
Access/format review
Status200 / permission unknown
The boundary claim stayed narrow
HTTP/2 and HTTP/3 semantic fields are interpreted within their display context; no actual frame/HPACK/QPACK or permission test is added.
Protocol evidence
Semantic fields / not encoded frames
Application trust gate
Headers / complete body separate
Access/format review
Display scope known / wire proof absent

ASSUMPTION · BOUNDARY · CONTROL

Protocol input and a trusted decision originate in different places

The request target and client headers are inputs to routing or content negotiation. Serving a protected resource still requires an Application permission decision. Atlas in a URL or Host field does not prove user identity, and 200 alone cannot prove correct access control.

The failure condition is treating client routing/context input as trusted identity or permission. Impact depends on the wrongly served resource. The control keeps canonical routing and resource permission decisions explicit; this lesson performs no authorization-bypass attempt.

Do not confuse a displayed format with the wire format

A tool can render an HTTP/2 response as readable status/header lines. That useful view is not the protocol parser’s wire format. An incorrect model can misidentify control data or body boundaries across versions.

Record version, display source, and completion state together. Receiving headers does not prove receipt of the whole representation; completeness depends on framing. The benign pair here is complete, while the loss branch explicitly records no response arrival.

Read every scenario without motion

Exchange match

The request belongs to one exchange
GET /notes/atlas-1?view=summary has requestObserved=true. Fragment details belongs to the browser URL and is not added to server-target evidence.
Request evidence
GET target observed / fragment excluded
Server observation
Server preparation
Browser evidence review
No browser receipt
Server preparation is not receipt
serverPreparedStatus=200 is supplied in this observation. Creating or preparing a response does not automatically change browser responseObserved state.
Request evidence
GET target observed / fragment excluded
Server observation
Prepared200 / receipt separate
Browser evidence review
No browser receipt
The browser observation was selected independently
The normal observation says the browser received status 200. That receipt is not the same observation as body completeness or UI display. Supplied content still needs its own framing and completion context.
Request evidence
GET target observed / fragment excluded
Server observation
Prepared200 / receipt separate
Browser evidence review
Observed200 / supplied content10
Request and response match within one context
The HTTP version determines connection/stream matching between a request and response. This example’s pair belongs to the same GET target; the fragment is excluded. When reviewing actual logs, do not attach another response without matching the contexts of both observation points.
Request evidence
Same exchange scope required
Server observation
Prepared200 / receipt separate
Browser evidence review
Observed200 / supplied content10
An inconsistent fixture differs from a gap
The selector flags requestObserved=false, responseObserved=true. Missing fields or a missing response may produce zero matches without proving correct runtime behavior; coverage is recorded separately.
Request evidence
Same exchange scope required
Server observation
Inconsistency predicate ≠ complete coverage
Browser evidence review
Observed200 / supplied content10
The completion verdict stays evidence-bound
The normal pair matches GET to 200/content. Actual server preparation comes from the server HTTP implementation; receipt/completeness comes from the client or a capture with known coverage. Body completion and UI display need separate measurement; the supplied pair is no real capture or permission test.
Request evidence
Same exchange scope required
Server observation
Inconsistency predicate ≠ complete coverage
Browser evidence review
Exchange consistent / other gates separate

Response absent

The request belongs to one exchange
GET /notes/atlas-1?view=summary has requestObserved=true. Fragment details belongs to the browser URL and is not added to server-target evidence.
Request evidence
GET target observed / fragment excluded
Server observation
Server preparation
Browser evidence review
No browser receipt
Server preparation is not receipt
serverPreparedStatus=200 is supplied in this observation. Creating or preparing a response does not automatically change browser responseObserved state.
Request evidence
GET target observed / fragment excluded
Server observation
Prepared200 / receipt separate
Browser evidence review
No browser receipt
The browser observation was selected independently
In the response-loss case, responseObserved is false and browserStatus is null. Preparing a 200 response at the server does not establish that the browser received it or explain the cause of a network loss.
Request evidence
GET target observed / fragment excluded
Server observation
Prepared200 / receipt separate
Browser evidence review
No observed response / browserStatus=null
Request and response match within one context
The HTTP version determines connection/stream matching between a request and response. This example’s pair belongs to the same GET target; the fragment is excluded. When reviewing actual logs, do not attach another response without matching the contexts of both observation points.
Request evidence
Same exchange scope required
Server observation
Prepared200 / receipt separate
Browser evidence review
No observed response / browserStatus=null
An inconsistent fixture differs from a gap
The selector flags requestObserved=false, responseObserved=true. Missing fields or a missing response may produce zero matches without proving correct runtime behavior; coverage is recorded separately.
Request evidence
Same exchange scope required
Server observation
Inconsistency predicate ≠ complete coverage
Browser evidence review
No observed response / browserStatus=null
The completion verdict stays evidence-bound
The server prepared 200, while browserStatus=null and responseObserved=false are supplied. In an actual review, bind server records and client receipt/completeness to the same request context. Missing client evidence proves neither a loss cause nor lack of processing; the cause is unknown here.
Request evidence
Same exchange scope required
Server observation
Inconsistency predicate ≠ complete coverage
Browser evidence review
UNKNOWN: response receipt/cause

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Read request and response within one exchange

Begin with method, target, status, relevant headers and completeness. Without request context, HEAD or POST 200 content can be misinterpreted. Actual HTTP matching follows the version’s connection/stream rules; application observations must also bind method, target, operation time and observation point to the same exchange. This artifact supplies its request/response pair without defining a custom correlation header.

The artifact XML selector finds responseObserved=true paired with requestObserved=false. The normal fixture selects zero rows and a deliberately inconsistent positive fixture selects one. Zero is not a server security measurement; missing observations, exchanges, or different capture scopes require more evidence.

Manual reading: mark boundaries before assigning meaning

Mark the first line, each header field, and the CRLF CRLF boundary in the inert pair. State whether the request has a body and identify the response content’s method/status context. Separately note the browser fragment and request-target query.

Then compare the pair with its semantic projection: GET and 200 remain while text start-lines disappear. This exercise sends no byte stream. Real traffic analysis needs separate verification of transport security, proxies, caching, and permission checks.

The consumer displaying this public note must associate the response with its GET and require message completion for a UI update expecting full content. Content-Length 10 describes ten bytes of Atlas note; seeing headers does not establish content arrival. In response-loss, serverPreparedStatus is 200 while browserStatus remains null. Do not manufacture a received 200 result in the UI; specify separate expectations for server preparation, client receipt and complete-content use.

NOW APPLY IT TO THE CASE

Which different claims are supported by routing, display format and receipt?

The GET target for the Atlas note carries path and query while the fragment stays in the browser. Preparing a 200 response does not prove browser receipt. An HTTP/2 or HTTP/3 semantic projection is not an encoded frame.

Evaluate the case’s 200, media type and parse-error records separately. Use representation rules to identify the remaining condition for usable data.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Atlas note: one pair, two representations

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

Read the raw artifact and field explanations

{
  "browserUrl": "https://library.atlas.example/notes/atlas-1?view=summary#details",
  "requestTarget": "/notes/atlas-1?view=summary",
  "fragment": "details",
  "http11": {
    "request": "GET /notes/atlas-1?view=summary HTTP/1.1\r\nHost: library.atlas.example\r\nAccept: text/plain\r\n\r\n",
    "response": "HTTP/1.1 200 OK\r\nDate: Thu, 08 Oct 2026 00:00:00 GMT\r\nContent-Type: text/plain; charset=utf-8\r\nContent-Length: 10\r\n\r\nAtlas note",
    "lineEnding": "CRLF",
    "body": "Atlas note",
    "bodyOctets": 10,
    "dateIsSynthetic": true
  },
  "semanticProjection": {
    "scope": "HTTP/2 and HTTP/3 shared semantic fields, not encoded frames",
    "request": {
      ":method": "GET",
      ":scheme": "https",
      ":authority": "library.atlas.example",
      ":path": "/notes/atlas-1?view=summary",
      "headers": {
        "accept": "text/plain"
      },
      "content": null
    },
    "response": {
      ":status": "200",
      "headers": {
        "content-type": "text/plain; charset=utf-8",
        "content-length": "10"
      },
      "content": "Atlas note"
    }
  },
  "observations": [
    {
      "case": "normal",
      "requestObserved": true,
      "serverPreparedStatus": 200,
      "responseObserved": true,
      "browserStatus": 200
    },
    {
      "case": "semantic-fields",
      "requestObserved": true,
      "serverPreparedStatus": 200,
      "responseObserved": true,
      "browserStatus": 200
    },
    {
      "case": "response-loss",
      "requestObserved": true,
      "serverPreparedStatus": 200,
      "responseObserved": false,
      "browserStatus": null
    }
  ],
  "selector": {
    "language": "XPath",
    "xml": "<observations><exchange requestObserved=\"true\" responseObserved=\"true\"/></observations>",
    "xpath": "count(/observations/exchange[@requestObserved=\"false\" and @responseObserved=\"true\"])",
    "expected": 0,
    "positiveFixtureXml": "<observations><exchange requestObserved=\"false\" responseObserved=\"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."
  }
}

http11: Original inert CRLF-delimited request/response, not a replay command.
semanticProjection: H2/3 semantic fields, without binary frames.
browserStatus: Unknown/null without response arrival; never copied from serverPreparedStatus.
selector: Consistency selector for instructional observations only.

Synthetic HTTPS origin with no TLS, proxy, stream-framing, or access-control runtime. Date is fixed, not a capture or measured server clock.

Two reality checks

The address-bar URL is copied directly into the request-line.

In this direct-origin HTTP/1.1 fixture the target is path/query, authority is in Host, and the fragment stays client-side. Other target forms depend on context.

Once the server prepares 200, the browser necessarily sees 200.

Response arrival is separate. Without it, the browser cannot infer the server status or processing result from that observation.

YOUR TURN

Work through this story.

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

In the response-loss branch, the server prepared 200 but responseObserved=false. What is the browser status?

The browser sees 200; server state automatically propagates to it.
In this fixture browserStatus=null; there is no evidence of receiving 200.

Read the explained answer

In this fixture browserStatus=null; there is no evidence of receiving 200. — Response construction does not guarantee delivery; browserStatus must derive from client observation.

Which two different HTTP fields do the Atlas note body and target show?

Selected lesson artifact fields; teaching example

requestTarget: /notes/atlas-1?view=summary
http11.body: Atlas note
http11.bodyOctets: 10

The target denotes the requested resource; the 10-octet body is response content.
The body is the browser URL fragment and is appended to the request target.

Read the explained answer

The target denotes the requested resource; the 10-octet body is response content. — Path/query belong to the request line; response content Atlas note is separated from headers by an empty CRLF line.

Why can the same GET and 200 be represented in HTTP/2–3 without HTTP/1.1 start-line bytes?

Read the explained answer

Method/authority/path and status semantics can persist across versions. The artifact supplies an H2/H3 :method/:path/:status projection, not encoded frames. The CRLF text pair is an HTTP/1.1 representation; real HPACK/QPACK/frame bytes cannot be inferred from the projection.

□ I separated semantics from framing.

□ I did not treat a projection as a packet capture.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

RFC 9110 — HTTP Semantics1.3 Core Semantics · 6 Message Abstraction · 6.1 Framing and Completeness · 6.2 Control Data · 6.4.1 Content Semantics · 7.1 Determining the Target Resource
RFC 9112 — HTTP/1.12.1 Message Format · 3 Request Line · 3.2.1 origin-form · 4 Status Line
MDN — HTTP messagesHTTP/1.1 messages · HTTP/2 messages · Pseudo-headers

YOUR NOTES / THIS BROWSER

HTTP request and response anatomy

1. Core · Mechanism

HTTP/1.1 pair

HTTP/2–3 semantic view

Response did not arrive

What agreement does HTTP establish?

Request: intent, target, and context

Response: decision, metadata, and content

Prepared at the server does not mean received by the browser

2. Red · Trust & Impact

Routing scope

Display scope

Protocol input and a trusted decision originate in different places

Do not confuse a displayed format with the wire format

3. Blue · Secure development & defense

Exchange match

Response absent

Read request and response within one exchange

Manual reading: mark boundaries before assigning meaning

Which different claims are supported by routing, display format and receipt?

Two reality checks

In the response-loss branch, the server prepared 200 but responseObserved=false. What is the browser status?

Which two different HTTP fields do the Atlas note body and target show?

Why can the same GET and 200 be represented in HTTP/2–3 without HTTP/1.1 start-line bytes?

Sources and scope