[GH-ISSUE #8110] [Bug] HAR import rejects the whole capture when a request URL keeps browser-unescaped `|`, `{`, `}` or `^` #4675

New issue

Closed

opened 2026-10-31 00:52:20 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:52:20 +00:00

Owner

Originally created by @kaoru0822-kitauji on GitHub (Oct 30, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8110

Originally assigned to: @kaoru0822-kitauji on GitHub.

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

inspect-web-network-capture <har> har and environment-build <har> reject an entire HAR whenever one request.url contains a character that browsers leave unescaped, such as |, {, } or ^. The whole capture fails with:

{"code":"invalid_request","details":{"issues":[{"path":["capture_path","/log/entries/8/request/url"],"reason":"invalid_format","message":"HAR schema validation failed: format (must match format \"uri\")."}]}}

har-schema@2.0.0 declares request.url as "format": "uri", and createHarValidator registers ajv-formats in its default full mode, which is a strict RFC 3986 regex. WHATWG URL serialization, which browsers use to record and send requests, keeps these characters as they are in the query (and | in the path):

new URL("https://fonts.googleapis.com/css?family=Roboto:400,700|Open+Sans").href
// "https://fonts.googleapis.com/css?family=Roboto:400,700|Open+Sans"
new URL('https://x.test/graphql?variables={"id":1}').href
// 'https://x.test/graphql?variables={%22id%22:1}'

Both serialized URLs are rejected.

Reproduction

All runs below were on main 317bf3fe2.

A real public HAR: HRussellZFAC023/yomu-reader scripts/fixtures/recorded/asahi-top/network.har (68 entries, sha256 0bc4435f…94bf). Entry 8 is a Google Fonts CSS URL with |. node scripts/rea.mjs inspect-web-network-capture network.har har --format json and node scripts/rea.mjs environment-build network.har --dry-run --format json both return the error above. None of the 68 records is inspected.
A minimal HAR: one Chrome-style entry whose request.url is either serialized URL above. It fails the same way at /log/entries/0/request/url. The same HAR with a plain URL is accepted.

Expected behavior

HAR 1.2 defines request.url as "Absolute URL of the request (fragments are not included)". It does not require RFC 3986 escaping. A URL exactly as a WHATWG URL serializer emits it should validate. Spellings that WHATWG would rewrite, such as http:\\user:pass@host/ or a tab inside the URL, can stay rejected, as they are today.

Impact and scope

The whole capture is refused, with no partial result. Google Fonts CSS v1 URLs (family=A|B), GraphQL GET requests (variables={…}), and analytics beacons with JSON in the query are common in browser HARs. I reproduced this with the public HAR above and with synthetic Chrome-style entries. I have not measured how often it happens across Chrome, Firefox and Playwright exports.

REA version

source main 317bf3fe2 (6.8.0)

Runtime and platform

Node 26.5.0; macOS 26 arm64

Target and artifact context

HAR 1.2 from a page recorder (public fixture above), plus synthetic Chrome-style entries

Interface

CLI

Earliest failure stage

Request parsing or validation

Relevant output or evidence

Shown above.

Typed outcome or recovery expected

Accept the record. If a URL really is invalid, the current typed invalid_request with a pointer is correct.

Analysis or suspected cause

This is source-derived. src/browser/history/HarSchema.ts already corrects other har-schema@2.0.0 deviations from HAR 1.2, such as timings, cache and durations. request.url's RFC 3986 uri format is not one of those corrections yet. Closed, unmerged PR #2044 tried a character-escaping approach and was closed by its author without a maintainer decision.

Originally created by @kaoru0822-kitauji on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8110 Originally assigned to: @kaoru0822-kitauji on GitHub. ### 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 `inspect-web-network-capture <har> har` and `environment-build <har>` reject an entire HAR whenever one `request.url` contains a character that browsers leave unescaped, such as `|`, `{`, `}` or `^`. The whole capture fails with: ```json {"code":"invalid_request","details":{"issues":[{"path":["capture_path","/log/entries/8/request/url"],"reason":"invalid_format","message":"HAR schema validation failed: format (must match format \"uri\")."}]}} ``` `har-schema@2.0.0` declares `request.url` as `"format": "uri"`, and `createHarValidator` registers ajv-formats in its default full mode, which is a strict RFC 3986 regex. WHATWG URL serialization, which browsers use to record and send requests, keeps these characters as they are in the query (and `|` in the path): ```js new URL("https://fonts.googleapis.com/css?family=Roboto:400,700|Open+Sans").href // "https://fonts.googleapis.com/css?family=Roboto:400,700|Open+Sans" new URL('https://x.test/graphql?variables={"id":1}').href // 'https://x.test/graphql?variables={%22id%22:1}' ``` Both serialized URLs are rejected. ### Reproduction All runs below were on main 317bf3fe2. 1. **A real public HAR:** [`HRussellZFAC023/yomu-reader` `scripts/fixtures/recorded/asahi-top/network.har`](https://github.com/HRussellZFAC023/yomu-reader/blob/main/scripts/fixtures/recorded/asahi-top/network.har) (68 entries, sha256 `0bc4435f…94bf`). Entry 8 is a Google Fonts CSS URL with `|`. `node scripts/rea.mjs inspect-web-network-capture network.har har --format json` and `node scripts/rea.mjs environment-build network.har --dry-run --format json` both return the error above. None of the 68 records is inspected. 2. **A minimal HAR:** one Chrome-style entry whose `request.url` is either serialized URL above. It fails the same way at `/log/entries/0/request/url`. The same HAR with a plain URL is accepted. ### Expected behavior HAR 1.2 defines `request.url` as "Absolute URL of the request (fragments are not included)". It does not require RFC 3986 escaping. A URL exactly as a WHATWG URL serializer emits it should validate. Spellings that WHATWG would rewrite, such as `http:\\user:pass@host/` or a tab inside the URL, can stay rejected, as they are today. ### Impact and scope The whole capture is refused, with no partial result. Google Fonts CSS v1 URLs (`family=A|B`), GraphQL GET requests (`variables={…}`), and analytics beacons with JSON in the query are common in browser HARs. I reproduced this with the public HAR above and with synthetic Chrome-style entries. I have not measured how often it happens across Chrome, Firefox and Playwright exports. ### REA version source main 317bf3fe2 (6.8.0) ### Runtime and platform Node 26.5.0; macOS 26 arm64 ### Target and artifact context HAR 1.2 from a page recorder (public fixture above), plus synthetic Chrome-style entries ### Interface CLI ### Earliest failure stage Request parsing or validation ### Relevant output or evidence Shown above. ### Typed outcome or recovery expected Accept the record. If a URL really is invalid, the current typed `invalid_request` with a pointer is correct. ### Analysis or suspected cause This is source-derived. `src/browser/history/HarSchema.ts` already corrects other `har-schema@2.0.0` deviations from HAR 1.2, such as timings, cache and durations. `request.url`'s RFC 3986 `uri` format is not one of those corrections yet. Closed, unmerged PR #2044 tried a character-escaping approach and was closed by its author without a maintainer decision.

bsakaguchi

2026-10-31 00:52:20 +00:00