morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #6537] [Bug] Pcap HTTP URI inventory loses absolute HTTP/1.0 targets without Host #3928

New issue

Closed

opened 2026-10-31 00:45:19 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:45:19 +00:00

Owner

Originally created by @coygeek on GitHub (Oct 23, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/6537

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Evidence, artifacts, or reconstruction

Observed behavior

Source-derived finding with a supporting production-parser probe: inspect_pcap_capture selects only TShark's generated http.request.full_uri field. In the released Wireshark source examined, that field requires a Host header even when the request target is already an absolute URI. A valid saved HTTP/1.0 proxy request can therefore lose its recorded URI from REA's inventory:

GET http://example.test/legacy?x=1 HTTP/1.0

The message ends with \r\n\r\n. REA's parser was directly observed returning an empty URI inventory, count zero, and partial: false when that generated field is absent. The native producer behavior for this message and the resulting public CLI/MCP response were not executed.

Reproduction

Executed once as one Node process, invoking the unchanged production function once for each case:

const layers = {
  "frame.number": ["1"],
  "frame.protocols": ["eth:ethertype:ip:tcp:http"],
  "ip.src": ["192.0.2.1"],
  "ip.dst": ["192.0.2.2"],
};
const uri = "http://example.test/legacy?x=1";
for (const fields of [
  layers,
  { ...layers, "http.request.full_uri": [uri] },
]) {
  console.log(await parseTsharkJsonOutput(
    JSON.stringify([{ _source: { layers: fields } }]),
  ));
}

parseTsharkJsonOutput was imported from src/pcap/PcapOutput.ts with the pinned Node runtime and locked tsx loader. These are synthetic selected-field JSON inputs, not captured native output. The first case models the output implied by the linked Wireshark source; the second is a generated-field control. No packet capture, external endpoint, native TShark, CLI or MCP run was performed.

Expected behavior

Preserve an absolute request URI already present in supported plaintext HTTP traffic, without requiring a redundant Host header. If a request target cannot be inventoried, report the omission explicitly.

The REA saved-capture guide advertises URI inventories. RFC 1945 §4.1 permits HTTP/1.0 requests with optional headers, and §5.1.2 defines absolute URI targets for proxy requests. This fixture does not need a guessed host or reconstructed URL.

Impact and scope

Provisional P2: silent inventory loss for this bounded class of saved HTTP/1.0 proxy traffic can hide an observed endpoint and undercount distinct request URIs. Original capture bytes remain unchanged. Real-capture occurrence and other Wireshark releases were not measured. The direct probe establishes parser behavior only; the wire-to-result chain is source-derived.

REA version

Package version 6.7.0; source revision e073f64be0a5a30c32d8b3cec23f9bd411080903. The published npm package was not executed.

Runtime and platform

Node.js v24.18.0, Linux 7.2.8-9-omarchy, x64; repository-locked dependencies and tsx loader. No TShark/capinfos executable was available on PATH. Wireshark v4.6.9 source was inspected, not run. Hopper/Ghidra are not involved.

Target and artifact context

Synthetic one-frame TShark selected-field JSON and its generated-URI control. The source-derived affected recording contains an HTTP/1.0 absolute-form GET request on a plaintext HTTP port, with no Host header. No private traffic or target data.

Interface

Other

Earliest failure stage

Native analysis or reconstruction

Relevant output or evidence

Actual parser outputs, reduced to relevant fields:

{"case":"no-generated-full-uri","packetCount":1,"httpRequestUris":[],"httpRequestUriCount":0,"partial":false}
{"case":"generated-full-uri-control","packetCount":1,"httpRequestUris":["http://example.test/legacy?x=1"],"httpRequestUriCount":1,"partial":false}

Initial evidence retained the exact probe, both complete inputs/results, runtime identity and source excerpts. No subsequent reproduction pass was performed.

Typed outcome or recovery expected

Successful capture Evidence with the observed absolute URI and count one; otherwise a stated URI-coverage limitation. Do not silently turn unavailable generated fields into evidence that no request URI was observed.

Analysis or suspected cause

Source-derived chain:

REA selects only full_uri.
Wireshark v4.6.9 constructs full_uri only when Host and request URI are available. It separately exposes the literal request URI.
REA aggregates only full_uri; its partial flag does not record this omission.
The provider maps those facts into public URI fields and complete coverage.

Selecting http.request.uri as well would make the already recorded absolute target available; no origin inference is needed for this case.

Additional context

GitHub issue searches covered both open and closed states for "http.request.full_uri" (no matches), "HTTP/1.0" (unrelated results), pcap URI, and "pcap" "HTTP" "URI". Additional searches used "proxy" "URI" and "pcap" "missing".

Closest reports were compared by body: #4180 and #4907 concern capinfos timestamps; #5734 rejects empty protocol stacks, whereas this probe has a nonempty HTTP stack and succeeds; #6130 concerns malformed-parent diagnostics. #3594 requests TLS decryption, whereas this request is plaintext. #3130 is a performance experiment, not URI preservation. None describes this field-selection root cause.

NOT_ENOUGH_INFO: a native TShark/public REA result for the wire fixture, first affected release, and a fully exercised alternate workflow. The sibling packet-field operation supports selecting http.request.uri, but that proposed workaround was not run.

Triage assessment

Impact level: P2
Assessment status: provisional
Impact basis: The selected-field/parser source chain predicts silent loss of an already absolute URI from valid saved HTTP/1.0 traffic. The direct parser probe confirms empty inventory and nonpartial status when the generated field is absent; native production of that absence remains source-derived.
Workaround status: unverified
Workaround basis: The sibling inspect_packet_capture operation accepts explicit http.request.uri field selection, but native field extraction and equivalent aggregate Evidence were not exercised.

Originally created by @coygeek on GitHub (Oct 23, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6537 ## Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ## Area Evidence, artifacts, or reconstruction ## Observed behavior Source-derived finding with a supporting production-parser probe: `inspect_pcap_capture` selects only TShark's generated `http.request.full_uri` field. In the released Wireshark source examined, that field requires a Host header even when the request target is already an absolute URI. A valid saved HTTP/1.0 proxy request can therefore lose its recorded URI from REA's inventory: ```http GET http://example.test/legacy?x=1 HTTP/1.0 ``` The message ends with `\r\n\r\n`. REA's parser was directly observed returning an empty URI inventory, count zero, and `partial: false` when that generated field is absent. The native producer behavior for this message and the resulting public CLI/MCP response were **not executed**. ## Reproduction Executed once as one Node process, invoking the unchanged production function once for each case: ```ts const layers = { "frame.number": ["1"], "frame.protocols": ["eth:ethertype:ip:tcp:http"], "ip.src": ["192.0.2.1"], "ip.dst": ["192.0.2.2"], }; const uri = "http://example.test/legacy?x=1"; for (const fields of [ layers, { ...layers, "http.request.full_uri": [uri] }, ]) { console.log(await parseTsharkJsonOutput( JSON.stringify([{ _source: { layers: fields } }]), )); } ``` `parseTsharkJsonOutput` was imported from `src/pcap/PcapOutput.ts` with the pinned Node runtime and locked tsx loader. These are synthetic selected-field JSON inputs, not captured native output. The first case models the output implied by the linked Wireshark source; the second is a generated-field control. No packet capture, external endpoint, native TShark, CLI or MCP run was performed. ## Expected behavior Preserve an absolute request URI already present in supported plaintext HTTP traffic, without requiring a redundant Host header. If a request target cannot be inventoried, report the omission explicitly. The [REA saved-capture guide](https://github.com/morluto/rea/blob/e073f64be0a5a30c32d8b3cec23f9bd411080903/docs/pcap-analysis.md#L1-L7) advertises URI inventories. [RFC 1945 §4.1](https://www.rfc-editor.org/rfc/rfc1945.html#section-4.1) permits HTTP/1.0 requests with optional headers, and [§5.1.2](https://www.rfc-editor.org/rfc/rfc1945.html#section-5.1.2) defines absolute URI targets for proxy requests. This fixture does not need a guessed host or reconstructed URL. ## Impact and scope Provisional P2: silent inventory loss for this bounded class of saved HTTP/1.0 proxy traffic can hide an observed endpoint and undercount distinct request URIs. Original capture bytes remain unchanged. Real-capture occurrence and other Wireshark releases were not measured. The direct probe establishes parser behavior only; the wire-to-result chain is source-derived. ## REA version Package version 6.7.0; source revision `e073f64be0a5a30c32d8b3cec23f9bd411080903`. The published npm package was not executed. ## Runtime and platform Node.js v24.18.0, Linux 7.2.8-9-omarchy, x64; repository-locked dependencies and tsx loader. No TShark/capinfos executable was available on PATH. Wireshark v4.6.9 source was inspected, not run. Hopper/Ghidra are not involved. ## Target and artifact context Synthetic one-frame TShark selected-field JSON and its generated-URI control. The source-derived affected recording contains an HTTP/1.0 absolute-form GET request on a plaintext HTTP port, with no Host header. No private traffic or target data. ## Interface Other ## Earliest failure stage Native analysis or reconstruction ## Relevant output or evidence Actual parser outputs, reduced to relevant fields: ```json {"case":"no-generated-full-uri","packetCount":1,"httpRequestUris":[],"httpRequestUriCount":0,"partial":false} {"case":"generated-full-uri-control","packetCount":1,"httpRequestUris":["http://example.test/legacy?x=1"],"httpRequestUriCount":1,"partial":false} ``` Initial evidence retained the exact probe, both complete inputs/results, runtime identity and source excerpts. No subsequent reproduction pass was performed. ## Typed outcome or recovery expected Successful capture Evidence with the observed absolute URI and count one; otherwise a stated URI-coverage limitation. Do not silently turn unavailable generated fields into evidence that no request URI was observed. ## Analysis or suspected cause Source-derived chain: - [REA selects only full_uri](https://github.com/morluto/rea/blob/e073f64be0a5a30c32d8b3cec23f9bd411080903/src/pcap/PcapProvider.ts#L64-L77). - [Wireshark v4.6.9 constructs full_uri only when Host and request URI are available](https://github.com/wireshark/wireshark/blob/v4.6.9/epan/dissectors/packet-http.c#L1688-L1704). It separately exposes the [literal request URI](https://github.com/wireshark/wireshark/blob/v4.6.9/epan/dissectors/packet-http.c#L2433-L2446). - [REA aggregates only full_uri](https://github.com/morluto/rea/blob/e073f64be0a5a30c32d8b3cec23f9bd411080903/src/pcap/PcapOutput.ts#L322-L334); its [partial flag does not record this omission](https://github.com/morluto/rea/blob/e073f64be0a5a30c32d8b3cec23f9bd411080903/src/pcap/PcapOutput.ts#L358-L365). - The provider [maps those facts into public URI fields and complete coverage](https://github.com/morluto/rea/blob/e073f64be0a5a30c32d8b3cec23f9bd411080903/src/pcap/PcapProvider.ts#L974-L982). Selecting `http.request.uri` as well would make the already recorded absolute target available; no origin inference is needed for this case. ## Additional context GitHub issue searches covered both open and closed states for `"http.request.full_uri"` (no matches), `"HTTP/1.0"` (unrelated results), `pcap URI`, and `"pcap" "HTTP" "URI"`. Additional searches used `"proxy" "URI"` and `"pcap" "missing"`. Closest reports were compared by body: [#4180](https://github.com/morluto/rea/issues/4180) and [#4907](https://github.com/morluto/rea/issues/4907) concern capinfos timestamps; [#5734](https://github.com/morluto/rea/issues/5734) rejects empty protocol stacks, whereas this probe has a nonempty HTTP stack and succeeds; [#6130](https://github.com/morluto/rea/issues/6130) concerns malformed-parent diagnostics. [#3594](https://github.com/morluto/rea/issues/3594) requests TLS decryption, whereas this request is plaintext. [#3130](https://github.com/morluto/rea/issues/3130) is a performance experiment, not URI preservation. None describes this field-selection root cause. NOT_ENOUGH_INFO: a native TShark/public REA result for the wire fixture, first affected release, and a fully exercised alternate workflow. The sibling packet-field operation supports selecting `http.request.uri`, but that proposed workaround was not run. ## Triage assessment - Impact level: P2 - Assessment status: provisional - Impact basis: The selected-field/parser source chain predicts silent loss of an already absolute URI from valid saved HTTP/1.0 traffic. The direct parser probe confirms empty inventory and nonpartial status when the generated field is absent; native production of that absence remains source-derived. - Workaround status: unverified - Workaround basis: The sibling inspect_packet_capture operation accepts explicit http.request.uri field selection, but native field extraction and equivalent aggregate Evidence were not exercised.

bsakaguchi closed this issue

2026-10-31 00:45:19 +00:00

bsakaguchi referenced this issue

2026-11-01 21:44:21 +00:00

[PR #5560] fix(browser): ensure cancellation deadline and teardown on hanging CDP calls #6962

bsakaguchi referenced this issue

2026-11-01 21:47:11 +00:00

[PR #6412] [MERGED] fix(screenshot): validate complete PNG IHDR #7341