WEB / WEB-08.04

One request across three HTTP transports

How are one method, target, and content carried across versions? Read three equivalent views separating semantics from wire format.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

HTTP/1.1

Common intent
Duru uses the same GET target and Accept preference; this branch is an independent exchange.
Client / Duru
GET /tea?view=plain; #details local
Atlas Application
Request absent
Local version mapping
Format not selected
Local mapping
The client prepares the GET /tea?view=plain request-line, Host: library.atlas.example and Accept: text/plain. Scheme comes from supplied HTTPS connection context; #details is excluded from the request-line.
Client / Duru
GET /tea?view=plain ready; Accept text/plain; awaiting response
Atlas Application
Request absent
Local version mapping
request-line + Host; HTTPS context
Request arrived
Atlas receives the complete request with matching semantic fields; no response has been prepared.
Client / Duru
GET /tea?view=plain ready; Accept text/plain; awaiting response
Atlas Application
GET received; target=/tea?view=plain
Local version mapping
request-line + Host; HTTPS context
Select representation
Atlas selects the same public text/plain representation; Çay is ready as four UTF-8 bytes.
Client / Duru
Waiting response
Atlas Application
200 ready; Çay=4 bytes
Local version mapping
request-line + Host; HTTPS context
Response arrived
The complete response reaches Duru; semantic status 200 and complete content are shown together.
Client / Duru
200 received; Çay=4 bytes
Atlas Application
200 ready; Çay=4 bytes
Local version mapping
request-line + Host; HTTPS context
Bound equivalence
Duru compares common fields without measuring compressed bytes or negotiation from these cards.
Client / Duru
Semantic match; wire bytes unmeasured
Atlas Application
Exchange complete
Local version mapping
request-line + Host; HTTPS context

HTTP/2

Common intent
Duru uses the same GET target and Accept preference; this branch is an independent exchange.
Client / Duru
GET /tea?view=plain; #details local
Atlas Application
Request absent
Local version mapping
Format not selected
Local mapping
HTTP/2 maps :method GET, :scheme https, :authority library.atlas.example, :path /tea?view=plain and accept text/plain. Stream 1 and usable HPACK context are supplied; the card does not generate encoded field bytes.
Client / Duru
GET /tea?view=plain ready; Accept text/plain; awaiting response
Atlas Application
Request absent
Local version mapping
:method/:scheme/:authority/:path; stream1
Request arrived
Atlas receives the complete request with matching semantic fields; no response has been prepared.
Client / Duru
GET /tea?view=plain ready; Accept text/plain; awaiting response
Atlas Application
GET received; target=/tea?view=plain
Local version mapping
:method/:scheme/:authority/:path; stream1
Select representation
Atlas selects the same public text/plain representation; Çay is ready as four UTF-8 bytes.
Client / Duru
Waiting response
Atlas Application
200 ready; Çay=4 bytes
Local version mapping
:method/:scheme/:authority/:path; stream1
Response arrived
The complete response reaches Duru; semantic status 200 and complete content are shown together.
Client / Duru
200 received; Çay=4 bytes
Atlas Application
200 ready; Çay=4 bytes
Local version mapping
:method/:scheme/:authority/:path; stream1
Bound equivalence
Duru compares common fields without measuring compressed bytes or negotiation from these cards.
Client / Duru
Semantic match; wire bytes unmeasured
Atlas Application
Exchange complete
Local version mapping
:method/:scheme/:authority/:path; stream1

HTTP/3

Common intent
Duru uses the same GET target and Accept preference; this branch is an independent exchange.
Client / Duru
GET /tea?view=plain; #details local
Atlas Application
Request absent
Local version mapping
Format not selected
Local mapping
HTTP/3 maps :method GET, :scheme https, :authority library.atlas.example, :path /tea?view=plain and accept text/plain. Stream 0 and usable QPACK context are supplied; the card does not generate encoded field bytes.
Client / Duru
GET /tea?view=plain ready; Accept text/plain; awaiting response
Atlas Application
Request absent
Local version mapping
:method/:scheme/:authority/:path; stream0
Request arrived
Atlas receives the complete request with matching semantic fields; no response has been prepared.
Client / Duru
GET /tea?view=plain ready; Accept text/plain; awaiting response
Atlas Application
GET received; target=/tea?view=plain
Local version mapping
:method/:scheme/:authority/:path; stream0
Select representation
Atlas selects the same public text/plain representation; Çay is ready as four UTF-8 bytes.
Client / Duru
Waiting response
Atlas Application
200 ready; Çay=4 bytes
Local version mapping
:method/:scheme/:authority/:path; stream0
Response arrived
The complete response reaches Duru; semantic status 200 and complete content are shown together.
Client / Duru
200 received; Çay=4 bytes
Atlas Application
200 ready; Çay=4 bytes
Local version mapping
:method/:scheme/:authority/:path; stream0
Bound equivalence
Duru compares common fields without measuring compressed bytes or negotiation from these cards.
Client / Duru
Semantic match; wire bytes unmeasured
Atlas Application
Exchange complete
Local version mapping
:method/:scheme/:authority/:path; stream0

ACTORS · STATE · DATA FLOW

Identify the question that stays the same

Duru requests /tea?view=plain on library.atlas.example using GET. In the example Atlas selects a text/plain representation and returns Çay. The selected method, target, request preference, status, and representation data can stay identical across versions. Three cards show alternative forms of this exchange rather than one request passing through three servers in sequence.

The browser URL is https://library.atlas.example/tea?view=plain#details. The query belongs to the target; the fragment stays in client context. Transport selection leaves TLS/server authority and permissions as separate questions. The fixture uses a public note that needs no user permission. Selecting a version grants no additional resource rights.

Map lines to control data

The direct-origin HTTP/1.1 view has a GET /tea?view=plain HTTP/1.1 request-line and a Host field. HTTPS connection context supplies the scheme in this example. CRLF CRLF ends the header section. The response status-line supplies 200, Content-Type supplies format, and Content-Length counts content octets. Çay has three characters and four UTF-8 bytes; the artifact uses one consistent byte calculation.

The HTTP/2 and HTTP/3 cards use :method=GET, :scheme=https, :authority=library.atlas.example, and :path=/tea?view=plain for the same control data. The response uses :status=200 without an OK reason phrase. These are not ordinary headers; accept and content-type appear separately. A text request-line is not a literal line carried inside a binary HEADERS frame.

Content-Length can still be four in this GET response projection, but it does not define HTTP/2–3 frame boundaries. DATA carries content while message/stream rules describe completion. These cards are not HEADERS or DATA captures. Frame headers, stream offsets, and compressed field bytes remain explicitly outside the displayed information.

Equivalent context does not mean identical bytes

HTTP/2 uses HTTP streams over TCP and HPACK context for field sections. HTTP/3 maps the same HTTP intent to QUIC streams with different QPACK state/dependency rules. An identical decoded field list can use literals in one context and references to earlier entries in another. Equal fields therefore establish neither equal compressed bytes nor equal total wire size.

Each scene starts independently for its selected version. The H1 card describes a complete text exchange, H2 an exchange mapped to one HTTP stream, and H3 an exchange mapped to a client-initiated bidirectional QUIC stream. Usable compression context is supplied. Connection establishment, negotiation, loss, and QPACK waiting are not measured by this comparison; WEB-08.02–03 develop those mechanisms separately.

Read every scenario without motion

Authority scope

The browser URL was separated into target components
The browser URL contains /tea?view=plain#details. The common request path is /tea?view=plain; details remains a client fragment. Authority library.atlas.example is selected routing context, not an authenticated user.
Request projection
GET /tea?view=plain / fragment excluded
Trust boundary review
Comparison pending
Application authority
No verdict
Host and pseudo-headers were tied to the same semantic question
H1 Host is mapped to H2/H3 :authority. These projections preserve routing meaning without turning client-selected authority text into trusted identity. Actual gateway-conversion behavior is not measured here.
Request projection
GET /tea?view=plain / fragment excluded
Trust boundary review
Host↔:authority / routing only
Application authority
No verdict
Public content was not treated as a protected grant
All three projections select ordinary public Çay content. Status 200 or a correct header list is not user/resource-permission evidence. A protected note would require an application decision about subject, action and object policy.
Request projection
GET /tea?view=plain / fragment excluded
Trust boundary review
Host↔:authority / routing only
Application authority
Public 200 / protected permission not inferred
Body metadata was separated from completion
The common response declares status 200 and contentOctets 4. H2/H3 header projections do not by themselves prove receipt of those four bytes. The fixture selects a completed exchange and omits intermediate partial-frame states.
Request projection
Metadata 200/4 / intermediate states omitted
Trust boundary review
Host↔:authority / routing only
Application authority
Public 200 / protected permission not inferred
Semantic and delivery evidence retained their layers
Decoded fields and application decisions are recorded separately. Equal normalized fields do not prove equal timing, omitted fields or the entire proxy chain. Transport observations and completion context need their own evidence.
Request projection
Metadata 200/4 / intermediate states omitted
Trust boundary review
Semantics equal / transport evidence separate
Application authority
Public 200 / protected permission not inferred
The trust conclusion stayed within the common fields
The selected method, target and content agree in these three authored alternatives. Production service parity or authorization is not verified. An apparently correct format conversion cannot skip the request’s permission gate.
Request projection
Metadata 200/4 / intermediate states omitted
Trust boundary review
Semantics equal / transport evidence separate
Application authority
Selected semantics equal / authz separate

Codec context

H2 and H3 field lists were not treated as wire bytes
H2 and H3 requestFieldsProjection use the same pseudo-header names. wireCapture is false. Displaying a decoded field does not establish measurement of its compressed bytes or negotiated protocol.
Request projection
H2/H3 decoded fields / wireCapture=false
Trust boundary review
Comparison pending
Application authority
No verdict
Codec selection retained its protocol-specific context
Usable HPACK context is supplied for HTTP/2 and QPACK context for HTTP/3. Equal :path text does not imply equal codec bytes. A dynamic reference depends on the decoder’s direction and table state.
Request projection
H2/H3 decoded fields / wireCapture=false
Trust boundary review
H2 HPACK / H3 QPACK / contexts supplied
Application authority
No verdict
Compression did not replace privacy decisions
Header compression is not content encryption. Normalizing a decoded list does not change whether a field is sensitive. Credential and private-content handling remain application predicates separate from transport presentation.
Request projection
H2/H3 decoded fields / wireCapture=false
Trust boundary review
H2 HPACK / H3 QPACK / contexts supplied
Application authority
Compression ≠ encryption or permission
H1 syntax was separated from other field displays
H1 carries a GET start-line, Host and CRLF delimiters; scheme comes from HTTPS connection context. H2/H3 have explicit :scheme fields. Omitting H1’s OK reason phrase from those projections does not lose the status.
Request projection
H1 text syntax / H2-H3 semantic fields
Trust boundary review
H2 HPACK / H3 QPACK / contexts supplied
Application authority
Compression ≠ encryption or permission
Byte comparison required the appropriate decoder
Equal meaning across versions does not permit feeding one version’s bytes to another parser. A maintained protocol decoder and correct context are required. These cards supply no compression-ratio or latency comparison.
Request projection
H1 text syntax / H2-H3 semantic fields
Trust boundary review
Use version-specific decoder and context
Application authority
Compression ≠ encryption or permission
Wire parity was not declared without measurement
The conclusion is equality of common semantic fields only. Compressed bytes, TLS and negotiation were not measured. A real parity claim requires separately observed exchanges with the same business inputs and policy.
Request projection
H1 text syntax / H2-H3 semantic fields
Trust boundary review
Use version-specific decoder and context
Application authority
Semantic match / wire parity unmeasured

ASSUMPTION · BOUNDARY · CONTROL

Revisit the trust boundary when the format changes

A gateway can translate a decoded request into a different protocol. Its task is to preserve method, target, and field meaning rather than convert client-selected authority text into trusted identity. The public tea example has a simple business decision. With a protected note, the Application still decides which user can perform which action.

The failure condition is treating a displayed field list as both parser output and permission evidence. Consequences include incorrect routing explanations, misleading audit correlation, or skipped access-control review. Record transport observations, decoded semantic messages, and application decisions separately. An inert projection cannot verify a real gateway.

Body completion differs from header availability. Seeing 200 does not prove Duru has received all four content bytes. The fixture selects a complete exchange at response arrival and omits intermediate partial-frame states. A review should preserve this boundary and document completion independently.

Do not treat compression state as a portable credential

A dynamic-table reference depends on decoder state for that connection and direction. A tool can display decoded accept while hiding the table that resolved its reference. HTTP/2 and HTTP/3 share pseudo-header names without sharing a codec; this lesson does not claim one protocol’s bytes are valid input to the other parser.

Use the correct protocol decoder and context before semantic comparison. Field compression is not content encryption and does not change whether a request is sensitive. Equal normalized records establish equality only for the selected common fields. Timing, dropped fields, privacy, and an entire proxy chain need separate evidence.

Read every scenario without motion

Field mapping

The common request field set was selected
The common request contains GET, https, library.atlas.example, /tea?view=plain and Accept text/plain with empty content. Review compares these selected fields, not every possible header.
Version ledger
GET / https / authority / path / accept
Semantic comparison
Comparison pending
Evidence verdict
No verdict
The request line and pseudo-headers were mapped
H1 GET maps to :method, target to :path and Host to :authority. The supplied H1 HTTPS schemeFrom context maps to :scheme https. Missing H1 start-line syntax in H2/H3 is not missing semantics.
Version ledger
GET / https / authority / path / accept
Semantic comparison
H1 fields map to H2/H3 pseudo-headers
Evidence verdict
No verdict
Status and content were compared separately
Each response projection has status 200. Content-Type text/plain; charset=utf-8 and Çay content agree. Çay occupies four UTF-8 bytes, not the size of a complete message or compressed frame.
Version ledger
Status 200 / media equal / content 4
Semantic comparison
H1 fields map to H2/H3 pseudo-headers
Evidence verdict
No verdict
Reason phrases were separated from field meaning
H1’s OK text is absent from H2/H3 :status 200. Numeric status meaning is preserved. Separating display differences from semantic loss prevents ordinary version differences from being classified as failures.
Version ledger
Status 200 / media equal / content 4
Semantic comparison
Numeric status equivalent / syntax differs
Evidence verdict
No verdict
The mapping verdict covered only selected fields
Method, authority, target, status, media and content agree in the ledger. Stream ID 1 is supplied for H2 and 0 for H3; these are not one shared protocol field. Runtime selection or service parity does not follow from mapping.
Version ledger
Status 200 / media equal / content 4
Semantic comparison
Numeric status equivalent / syntax differs
Evidence verdict
Selected field mapping consistent
Regression retained decoder scope
An H1 parser can supply request-line/Host plus HTTPS connection context; H2/H3 decoders can supply pseudo-fields and content. Correlate records for the same exchange and response direction. These projections provide expected fields, not measurements of negotiated version, decoder state or actual completion.
Version ledger
Status 200 / media equal / content 4
Semantic comparison
Numeric status equivalent / syntax differs
Evidence verdict
Semantic comparison only / wire capture absent

Fragment gap

The fragment selector retained its normal scope
Normal XML reports fragmentIncluded false for all three versions, yielding zero matches. The browser URL includes fragment details, but the common path and decoded :path exclude it.
Version ledger
Three normal observations: fragmentIncluded=false
Semantic comparison
Comparison pending
Evidence verdict
No verdict
The positive control selected incorrect inclusion
The separate positive XML reports fragmentIncluded true for version 2 and yields one match. It tests the oracle’s field predicate, not a real-browser fragment transmission. Authored observations and protocol measurement remain separate.
Version ledger
Three normal observations: fragmentIncluded=false
Semantic comparison
Positive fixture: inclusion=true / count 1
Evidence verdict
No verdict
A missing request observation did not become a normal row
The alternative review lacks one version’s normalized-request observation. Two false rows cannot establish the third version’s behavior. Copying all three normal-fixture rows into the incomplete trace would conceal the gap.
Version ledger
One version observation missing
Semantic comparison
Positive fixture: inclusion=true / count 1
Evidence verdict
No verdict
Exact coverage was checked before interpreting zero matches
The selector counts only existing true rows; a missing row adds no match. Zero therefore does not imply review of all three versions. The gate separately compares required versions and observed-field inventories.
Version ledger
One version observation missing
Semantic comparison
Zero count / required-version coverage incomplete
Evidence verdict
No verdict
The missing version retained an unknown verdict
Observed rows can be reviewed within scope; fragment handling for the missing version remains UNKNOWN. A standard’s expectation does not replace observation of an implementation. Missing evidence proves neither compliance nor violation.
Version ledger
One version observation missing
Semantic comparison
Zero count / required-version coverage incomplete
Evidence verdict
UNKNOWN: missing-version fragment observation
A minimal record was selected for new evidence
For the missing version, obtain the normalized target formed by the client HTTP stack and a receiver record covering the same exchange. Keep the browser URL fragment separate from the transmitted target. Sensitive query values can be redacted; false in the projection cannot replace an unobserved request.
Version ledger
One version observation missing
Semantic comparison
Zero count / required-version coverage incomplete
Evidence verdict
Needed: version/target/field coverage

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Check manually using a mapping ledger

Separate browserUrl, target, and fragment in the artifact. Map the H1 request-line to H2/H3 :method and :path, Host to :authority, and HTTPS context to :scheme. Mark numeric response status, media type, and content bytes separately. The absence of the H1 OK text in the other cards is not a semantic loss.

Encode Çay as UTF-8 and count four bytes. Tie that count to H1 Content-Length without interpreting matching H2/H3 metadata as frame size. No H1 connection-specific fields are carried into the H2/H3 cards. Reading valid examples teaches this boundary without transmitting malformed inputs.

The selector searches normalized request observations for fragmentIncluded=true. Normal and deliberately inconsistent positive fixtures return 0 and 1. A missing observation also returning 0 does not prove fragments were excluded. These are authored observations, not standard access-log fields.

Keep evidence proportional to what was observed

A useful manual conclusion is: common semantic fields match; wire bytes were not displayed. The cards cannot establish compression ratio, latency, or browser protocol selection. Real capture analysis needs the negotiated version, decoder context, and exchange completion together.

Different versions do not guarantee identical application behavior. Route, negotiation, and policy implementations can differ. These three projections were authored with one selected result and are not a service-parity test. Actual parity requires normal exchange evidence compared under the same business input and policy.

NOW APPLY IT TO THE CASE

Which trust and runtime questions remain after common request fields match?

The public /tea?view=plain request appears as H1 text and H2/H3 decoded fields. All select Çay content and exclude the details fragment from the target. Equal meaning does not imply equal compressed bytes or production-policy results.

Which application conditions would remain if the case used another HTTP transport? Do not equate stream or packet completion with successful note parsing.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Three views of one benign exchange

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/tea?view=plain#details",
  "fragment": "details",
  "commonRequest": {
    "method": "GET",
    "scheme": "https",
    "authority": "library.atlas.example",
    "path": "/tea?view=plain",
    "headers": {
      "accept": "text/plain"
    },
    "content": ""
  },
  "commonResponse": {
    "status": 200,
    "contentType": "text/plain; charset=utf-8",
    "content": "Çay",
    "contentOctets": 4
  },
  "http11": {
    "request": "GET /tea?view=plain HTTP/1.1\r\nHost: library.atlas.example\r\nAccept: text/plain\r\n\r\n",
    "schemeFrom": "supplied HTTPS connection context",
    "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: 4\r\n\r\nÇay"
  },
  "http2": {
    "streamIdSupplied": 1,
    "requestFieldsProjection": {
      ":method": "GET",
      ":scheme": "https",
      ":authority": "library.atlas.example",
      ":path": "/tea?view=plain",
      "accept": "text/plain"
    },
    "responseFieldsProjection": {
      ":status": "200",
      "content-type": "text/plain; charset=utf-8",
      "content-length": "4"
    },
    "content": "Çay",
    "compression": "HPACK context supplied usable",
    "wireCapture": false
  },
  "http3": {
    "requestStreamIdSupplied": 0,
    "requestFieldsProjection": {
      ":method": "GET",
      ":scheme": "https",
      ":authority": "library.atlas.example",
      ":path": "/tea?view=plain",
      "accept": "text/plain"
    },
    "responseFieldsProjection": {
      ":status": "200",
      "content-type": "text/plain; charset=utf-8",
      "content-length": "4"
    },
    "content": "Çay",
    "compression": "QPACK context supplied usable",
    "wireCapture": false
  },
  "selector": {
    "language": "XPath",
    "xml": "<observations><request version=\"1.1\" fragmentIncluded=\"false\"/><request version=\"2\" fragmentIncluded=\"false\"/><request version=\"3\" fragmentIncluded=\"false\"/></observations>",
    "xpath": "count(/observations/request[@fragmentIncluded=\"true\"])",
    "expected": 0,
    "positiveFixtureXml": "<observations><request version=\"2\" fragmentIncluded=\"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."
  }
}

commonRequest: Semantic comparison fields; the fragment is excluded from the target.
http11: Valid CRLF text syntax with scheme supplied by connection context.
requestFieldsProjection: Decoded pseudo-headers and ordinary fields, not compressed wire bytes.
contentOctets: Four UTF-8 bytes for Çay, not a whole-message or frame size.

Three authored alternative exchanges; H2/H3 fields are semantic projections. TLS, negotiation, actual compressed bytes, and production permissions are not measured.

Two reality checks

GET and headers displayed for H2/H3 mean H1 text traveled on the wire.

Tools render binary protocols as readable semantics; a start-line differs from compressed field bytes.

Matching fields and body imply identical wire bytes.

Framing, stream mapping, and compression state differ; only selected semantic equality is shown.

YOUR TURN

Work through this story.

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

HTTP/1.1 Host and H2/H3 :authority carry the same selected authority. Does that imply identical wire bytes?

Yes; all three versions send identical start-line and header bytes.
No; the same authority is represented through different framing/compression.

Read the explained answer

No; the same authority is represented through different framing/compression. — CommonRequest authority is preserved; H1 text and H2/H3 field projections are not wire-equivalent bytes.

Çay content matches in all three representations. Which evidence boundary still applies?

Selected lesson artifact fields; teaching example

commonResponse: {"status":200,"contentType":"text/plain; charset=utf-8","content":"Çay","contentOctets":4}
http2.wireCapture: false
http3.wireCapture: false

Content semantics match; H2/H3 wire capture is not established.
Matching content validates all protocol implementations.

Read the explained answer

Content semantics match; H2/H3 wire capture is not established. — WireCapture=false; comparing the four-octet body does not establish HPACK/QPACK/native-connection execution.

H1 uses schemeFrom connection context while H2/H3 have :scheme. How does this preserve request meaning?

Read the explained answer

H1 GET /tea?view=plain does not show a scheme; it comes from supplied HTTPS context. H2/H3 projections carry :scheme=https for the same common semantic context. Fragment details is appended to no request path. Context mapping does not imply byte or security-guarantee equality.

□ I identified the connection context for the H1 scheme.

□ I excluded the fragment from the request path.

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 · 7.1 Determining the Target Resource · 8.6 Content-Length · 8.8.1 Weak versus Strong · 8.8.3 ETag · 8.8.3.2 Comparison · 8.8.3.3 Example: Entity Tags Varying on Content-Negotiated Resources · 13.1.1 If-Match · 13.1.2 If-None-Match · 13.2.1 When to Evaluate · 15.4.5 304 Not Modified · 15.5.13 412 Precondition Failed
RFC 9112 — HTTP/1.12.1 Message Format · 3.2.1 origin-form · 6.3 Message Body Length
RFC 9113 — HTTP/24.3 Field Section Compression and Decompression · 8.1 HTTP Message Framing · 8.2.2 Connection-Specific Header Fields · 8.3.1 Request Pseudo-Header Fields · 8.3.2 Response Pseudo-Header Fields
RFC 9114 — HTTP/33.1 Discovering an HTTP/3 Endpoint · 4.1 HTTP Message Framing · 4.2.1 Field Compression · 4.3.1 Request Pseudo-Header Fields · 4.3.2 Response Pseudo-Header Fields

YOUR NOTES / THIS BROWSER

One request across three HTTP transports

1. Core · Mechanism

HTTP/1.1

HTTP/2

HTTP/3

Identify the question that stays the same

Map lines to control data

Equivalent context does not mean identical bytes

2. Red · Trust & Impact

Authority scope

Codec context

Revisit the trust boundary when the format changes

Do not treat compression state as a portable credential

3. Blue · Secure development & defense

Field mapping

Fragment gap

Check manually using a mapping ledger

Keep evidence proportional to what was observed

Which trust and runtime questions remain after common request fields match?

Two reality checks

HTTP/1.1 Host and H2/H3 :authority carry the same selected authority. Does that imply identical wire bytes?

Çay content matches in all three representations. Which evidence boundary still applies?

H1 uses schemeFrom connection context while H2/H3 have :scheme. How does this preserve request meaning?

Sources and scope