morluto/rea

Fork 0

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

[PR #1509] [MERGED] fix(browser): accept HAR files that begin with a byte-order mark #2928

New issue

Closed

opened 2026-10-17 21:11:55 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-17 21:11:55 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/1509
Author: @kaoru0822-kitauji
Created: 10/10/2026
Status: ✅ Merged
Merged: 10/10/2026
Merged by: @kaoru0822-kitauji

Base: main ← Head: fix/har-byte-order-mark

📝 Commits (1)

3f7d993 fix(browser): accept HAR files that begin with a byte-order mark

📊 Changes

3 files changed (+40 additions, -12 deletions)

View changed files

📝 src/browser/history/HarCapture.test.ts (+21 -1)
📝 src/browser/history/HarCapture.ts (+14 -0)
📝 src/browser/history/HarCaptureProcess.ts (+5 -11)

📄 Description

Summary

inspect_web_network_capture rejected any HAR file that starts with a UTF-8 byte-order mark:

$ rea inspect-web-network-capture bom.har har --format json
{"code":"invalid_request", … "issues":[{"path":["capture_path",""],"reason":"invalid_format","message":"HAR is malformed JSON."}]}

The HAR 1.2 specification's encoding section says the file must be UTF-8, that the reader must ignore a byte-order mark if one exists, and that the writer may emit one. Some HAR writers do emit it.

The cause is a WHATWG naming trap in HarCaptureProcess.ts:

new TextDecoder("utf-8", { fatal: true, ignoreBOM: true })

ignoreBOM: true means "do not treat the BOM specially", so it stays in the output ("{…}") and jsonc-parser then reports malformed JSON. The default (ignoreBOM: false) skips one leading mark.

Change

New decodeHarText(bytes) in HarCapture.ts decodes strict UTF-8 with the default BOM handling and keeps the existing HAR is not valid UTF-8 JSON. failure. HarCaptureProcess uses it.
Only one leading mark is skipped. A second mark is content and still fails as malformed JSON.
The artifact SHA-256 and byte count are still computed over the exact selected file bytes.

Verification

A new test in src/browser/history/HarCapture.test.ts covers four cases: a BOM-prefixed fixture decodes to the same capture as the plain one, a double BOM is still malformed, and invalid UTF-8 still fails. It fails on main at the first assertion.
npx vitest run src/browser/history passes (61 tests).
npm run test:focused -- tests/boundary/browser/historicalCaptureDecoder.test.ts tests/boundary/mcp/webNetworkCaptureMcp.test.ts tests/acceptance/tools/historicalCaptureResources.test.ts src/browser/history/CaptureFailures.test.ts passes (28 tests).
I ran the CLI by hand: the BOM-prefixed HAR now returns one record, as the plain file does.
npm run check:fast and npm run docs:check pass.

🤖 Generated with Claude Code

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/1509 **Author:** [@kaoru0822-kitauji](https://github.com/kaoru0822-kitauji) **Created:** 10/10/2026 **Status:** ✅ Merged **Merged:** 10/10/2026 **Merged by:** [@kaoru0822-kitauji](https://github.com/kaoru0822-kitauji) **Base:** `main` ← **Head:** `fix/har-byte-order-mark` --- ### 📝 Commits (1) - [`3f7d993`](https://github.com/morluto/rea/commit/3f7d993ae486c7f68287a66c133f944ca8a36acf) fix(browser): accept HAR files that begin with a byte-order mark ### 📊 Changes **3 files changed** (+40 additions, -12 deletions) <details> <summary>View changed files</summary> 📝 `src/browser/history/HarCapture.test.ts` (+21 -1) 📝 `src/browser/history/HarCapture.ts` (+14 -0) 📝 `src/browser/history/HarCaptureProcess.ts` (+5 -11) </details> ### 📄 Description ## Summary `inspect_web_network_capture` rejected any HAR file that starts with a UTF-8 byte-order mark: ``` $ rea inspect-web-network-capture bom.har har --format json {"code":"invalid_request", … "issues":[{"path":["capture_path",""],"reason":"invalid_format","message":"HAR is malformed JSON."}]} ``` The HAR 1.2 specification's encoding section says the file must be UTF-8, that the reader must ignore a byte-order mark if one exists, and that the writer may emit one. Some HAR writers do emit it. The cause is a WHATWG naming trap in `HarCaptureProcess.ts`: ```ts new TextDecoder("utf-8", { fatal: true, ignoreBOM: true }) ``` `ignoreBOM: true` means "do not treat the BOM specially", so it stays in the output (`"{…}"`) and `jsonc-parser` then reports malformed JSON. The default (`ignoreBOM: false`) skips one leading mark. ## Change - New `decodeHarText(bytes)` in `HarCapture.ts` decodes strict UTF-8 with the default BOM handling and keeps the existing `HAR is not valid UTF-8 JSON.` failure. `HarCaptureProcess` uses it. - Only one leading mark is skipped. A second mark is content and still fails as malformed JSON. - The artifact SHA-256 and byte count are still computed over the exact selected file bytes. ## Verification - A new test in `src/browser/history/HarCapture.test.ts` covers four cases: a BOM-prefixed fixture decodes to the same capture as the plain one, a double BOM is still malformed, and invalid UTF-8 still fails. It fails on `main` at the first assertion. - `npx vitest run src/browser/history` passes (61 tests). - `npm run test:focused -- tests/boundary/browser/historicalCaptureDecoder.test.ts tests/boundary/mcp/webNetworkCaptureMcp.test.ts tests/acceptance/tools/historicalCaptureResources.test.ts src/browser/history/CaptureFailures.test.ts` passes (28 tests). - I ran the CLI by hand: the BOM-prefixed HAR now returns one record, as the plain file does. - `npm run check:fast` and `npm run docs:check` pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-17 21:11:55 +00:00

closed this issue
added the
pull-request
label

bsakaguchi referenced this issue

2026-10-31 01:07:06 +00:00

[PR #2928] [CLOSED] fix(process): count one unreadable child once during cleanup #5497

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#2928

No description provided.

Rows
Columns