[Antruly]

Summary

uvp_http_request reported only the normalised headers map. A response with
two Set-Cookie lines came back as one comma-joined value, names were
lower-cased, and the order was gone — so a proxy-shaped consumer could not
reconstruct the response.

The HTTP/1.1 client now reports headers_raw: the response headers in wire
order, one entry per line, with the peer's spelling and duplicates kept.
headers stays the convenience view.

Fixes #277

Problem and expected behavior

Smallest trigger, as the owner reproduced it at bc17f63: a local server sending
two Set-Cookie and two X-Dupe lines yields

"headers": { "set-cookie": "a=1; Path=/, b=2; Path=/", "x-dupe": "one, two" }

Expected: the ordered, duplicate-preserving list beside it, so a consumer can
put the response back together.

Change and scope

• application/httpClient.ts: HttpExchange.rawHeaders carries the HTTP/1.1
  response's rawHeaders as {name, value} entries. HTTP/2 sets it to
  undefined — Node folds the response before uvp sees it — and the HTTP/3
  probe and a WebSocket handshake report only the parsed map, so they do the same.
• application/WebService.ts / httpToolOutput.ts: the result carries
  headers_raw when the transport exposed a raw list.
• contracts/webToolContracts.ts: the output gains optional headers_raw,
  documented as transport-dependent, and docs/public/tool-catalog.json is
  regenerated.
• tests/conformance/fixtures/fixtureServer.mjs: a /duplicate-headers route
  written as raw header pairs (the only form Node sends without folding).
• tests/conformance/httpBehaviour.test.ts: one case asserts order, spelling and
  duplicates over HTTP/1.1 and that the map still shows what it lost; a second
  runs a real h2c server and asserts the field is absent, not an empty list.

Intentionally not included: the body.bytes half of the issue. The owner could
not reproduce it, bytes is a number on every transport observed, and the schema
and projection already declare z.number().int(); re-scoping it would be a change
with no observed defect behind it.

Not applicable: scope/authority decisions — no new provider, credential, or
network boundary; the request already contacts the URL the caller names.

Contract and boundary impact

• Earliest changed layer: application, then contracts
• Tool contract changes, and whether docs/public/tool-catalog.json was regenerated: yes — uvp_http_request output gains optional headers_raw; regenerated with npm run docs:generate, and npm run docs:check passes.
• libuvcpp feature mapping changes: none.
• Generated-code impact: none.
• Evidence, unknown, or error-contract semantics: absence of headers_raw states that this transport exposed no raw list; it is not an empty response.
• Generated metadata, package, or installation impact: none.

Expected effects:

• Read files on the local filesystem.
• Write files, including generated workspaces and build directories.
• Compile or link C++ via CMake.
• Start or stop a process.
• Open a listening socket.
• Make an outbound network request.
• Record or persist captured traffic.
• Documentation or usability only; no runtime effect.
• Not sure yet; needs maintainer guidance.

Evidence and regression coverage

• Tests added or updated: tests/conformance/httpBehaviour.test.ts (two cases, above) and the fixture route.
• Base reproduction: the owner's review on [http] --json collapses duplicate response headers and types body.bytes as a string #277, at bc17f63, showed the two collapsed headers in headers with no raw list. The new presence case fails with the capture removed (expected undefined to be defined); the absence case fails when the projection emits [] instead of omitting the field (expected … to not have property "headers_raw").
• The exact command a reviewer can run:
  LIBUVCPP_ROOT=/home/zwy/下载/libuvcpp-1.7.0-linux-x64 PKG_CONFIG_PATH=$LIBUVCPP_ROOT/lib/pkgconfig LD_LIBRARY_PATH=$LIBUVCPP_ROOT/lib npm run check:pr
• Remaining proof gaps: HTTP/2 and HTTP/3 have no raw list by construction, so the absence path is the only one their stacks can exercise — tested for h2c with a real session, not for HTTP/3 (that needs a QUIC target). Header ordering across redirects follows the final hop, like the rest of the exchange.

For evidence-bearing changes:

• Observed, derived, and inferred claims remain distinguishable in the output.
• Coverage that was not examined is reported as unknown, not complete.
• A check that could not run yields undetermined, not a fabricated yes or no.
• Resource kinds and provenance survive the boundary unchanged.

Validation performed

• npm run compile — exit 0.

• npx vitest run tests/conformance/httpBehaviour.test.ts — 14 passed.

• Two mutation probes (restored afterwards): dropping the raw capture → 1 failed; emitting [] instead of omitting → 1 failed.

• Full npx vitest run with libuvcpp 1.7.0 — 1674 passed, 14 skipped, and the same two host-environmental real-toolchain files that fail on an untouched tree (nativeProbeGate lacks the C ABI in the host install; realToolchain has port 8090 held by an unrelated process).

• npm run docs:check, npm run typecheck, npm run lint, npm run format:check — exit 0.

• A template change was generated, built, and run against a real libuvcpp install.

• Not applicable (no template or libuvcpp-facing change).

Compatibility, safety, and release

• Breaking changes or migration steps: none — an optional output field; headers is unchanged.
• libuvcpp version floor impact: none.
• New network exposure or listening behaviour: none.
• Package or release metadata impact: none.

Author readiness

Human owner: @Antruly

• I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
• I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
• I declare this PR ready for initial maintainer review.

Before merge

• This PR addresses a concrete problem or an agreed enhancement.
• Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
• The PR has one focused outcome and the title follows type(scope): outcome.
• Related issue is linked, or the reason for not linking one is stated above.
• Tests cover the changed observable behaviour and its meaningful failure paths.
• Owning docs, contracts, and generated metadata are updated where needed.
• User-visible CLI or MCP changes include representative output.
• I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

🤖 Antruly-dev-1 · AI Engineer 1 · agent:dev-ai-1

[Antruly]

Review at f32bc23

The header half of #277 reproduces and is fixed; the excluded body.bytes half is excluded for the same reason I reported on the issue.

• End-to-end through the CLI against a local server writing two Set-Cookie and two X-Dupe lines:
  • headers_raw = [{"name":"Set-Cookie","value":"a=1; Path=/"},{"name":"Set-Cookie","value":"b=2; Path=/"},{"name":"X-Dupe","value":"one"},{"name":"X-Dupe","value":"two"},…] — wire order, original spelling, duplicates kept.
  • headers is unchanged: "set-cookie": "a=1; Path=/, b=2; Path=/", "x-dupe": "one, two".
• npx vitest run tests/conformance/httpBehaviour.test.ts → 14 passed; the h2c case asserts headers_raw is absent rather than [], which is the honest claim for a transport that folds.
• npm run compile, npm run docs:check, npm run typecheck exit 0. The field is optional in the contract and the regenerated catalog; headers is untouched, so this is additive.

Non-blocking (my judgment): the human renderer still shows only headers; the raw list is visible through --json and MCP. That matches the issue's proxy-consumer use — a CLI rendering change would be separate. headers_raw describes the final hop of a redirect chain, which the body states.

No blocking findings.

[Antruly]

🤖 Antruly-dev-1 · AI Engineer 1 · agent:dev-ai-1

Thanks — the CLI reproduction is the observation I could not make from the lane, and it confirms the ordering and duplicates exactly.

On the non-blocking note: agreed that the human renderer should keep showing the map. headers_raw exists so a program can reconstruct the response; a CLI rendering of repeated lines would be a separate decision about that view, and I have not changed the head for it. f32bc23 is the reviewed tree, CI is green, and approval is the only gate left.

[Antruly]

Approved.

Reviewed head f32bc23daf3b30db27fc333d83dddfae4fd3ede4.

• Fixes the header half of [http] --json collapses duplicate response headers and types body.bytes as a string #277: headers_raw carries the HTTP/1.1 response headers in wire order, with the peer's spelling and duplicates; headers is unchanged. Verified end to end through the CLI against a server sending two Set-Cookie and two X-Dupe lines.
• npx vitest run tests/conformance/httpBehaviour.test.ts → 14 passed; the h2c case asserts the field is absent rather than [].
• npm run compile, npm run docs:check, npm run typecheck exit 0; catalog regenerated.
• All check runs green at this head (CI required, Documentation, Static checks, shards, portable, packaged rehearsal, Windows source gates); git merge-tree --write-tree origin/main pr285 exit 0 against a2ad225; readiness declaration present.

Merging with --match-head-commit.