fix(respect): record request bodies in the HAR postData entry

[ariesclark]

What/Why/How?

withHar recorded postData: {} for every request, so a HAR from respect --har-output never contained the request body. Replaying that capture through drift skips request-body validation and reports no problems. Missing data reads as a pass.

buildPostData serializes the body and reads the mime type from the request's content-type, going through buildHeaders so it treats every header shape alike. It records only text bodies, omitting FormData, streams, and binary rather than stringifying them to [object Object]. request.bodySize now carries the byte length instead of -1.

Reference

None.

Testing

build-post-data.test.ts covers the content-type sources, the application/octet-stream fallback, and the cases that must record nothing: no body, empty string, Buffer, FormData, plain object.

Check yourself

• This PR follows the contributing guide
• All new/updated code is covered by tests
• Core code changed? - Tested with other Redocly products (internal contributions only)
• New package installed? - Tested in different environments (browser/node)
• Documentation update has been considered

Security

• The security impact of the change has been considered
• Code follows company security practices and guidelines

The HAR now stores request bodies verbatim, so capturing a login flow puts credentials in the file. The capture already recorded headers and response bodies unmasked, so this widens an existing exposure rather than adding a new kind.

---

Note

Low Risk
Scoped to HAR logging in respect; it persists request bodies in capture files (including possible secrets), extending exposure similar to headers/responses already recorded.

Overview
respect --har-output now writes request bodies into each HAR entry’s postData, instead of always emitting an empty object, so replays (e.g. through drift) can validate request bodies instead of treating missing data as success.

A new buildPostData helper serializes string and URLSearchParams bodies, resolves Content-Type via the same buildHeaders path as the rest of the HAR entry (including casing and alternate header shapes), and falls back to application/octet-stream or form-urlencoded when appropriate. It skips bodies it cannot represent safely (empty/no body, Buffer, FormData, plain objects). withHar uses that helper and sets request.bodySize from the recorded text when possible, or 0 / -1 when there is no body vs. a body that was not recorded.

Unit tests cover content-type handling, fallbacks, and omit cases.

^{Reviewed by Cursor Bugbot for commit d0c4d82. Bugbot is set up for automated code reviews on this repo. Configure here.}

[changeset-bot]

🦋 Changeset detected

Latest commit: d0c4d82

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
@redocly/cli	Patch
@redocly/openapi-core	Patch
@redocly/respect-core	Patch
@redocly/client-generator	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[DmitryAnansky]

@ariesclark
Could you please clarify what you mean by “never contained the request body”?
Below is an example of a HAR log entry for a POST request. It contains both the request (including the request body) and the response.

If I understand correctly, the main issue is that the postData field is missing. Is that right?

{
        "_compressed": false,
        "_resourceType": "fetch",
        "_timestamps": {
          "start": [
            310944,
            99464625
          ],
....
        },
        "timings": {
 ....
        },
        "time": 324.604041,
        "startedDateTime": "2026-07-31T08:53:25.073Z",
        "cache": {
          "beforeRequest": null,
          "afterRequest": null
        },
        "request": {
          "method": "POST",
          "url": "https://redocly.com/_mock/demo/openapi/museum-api/tickets",
          "cookies": [],
          "headers": [
            {
              "name": "content-type",
              "value": "application/json"
            },
            {
              "name": "accept",
              "value": "application/json, application/problem+json"
            },
            {
              "name": "authorization",
              "value": "Basic Og=="
            }
          ],
          "queryString": [],
          "headersSize": -1,
          "bodySize": -1,
          "postData": {},
          "httpVersion": "HTTP/1.1"
        },
        "response": {
          "headers": [
            {
              "name": "access-control-allow-headers",
              "value": "*"
            },
            .....
          ],
          "cookies": [],
          "status": 201,
          "statusText": "Created",
          "httpVersion": "HTTP/1.1",
          "redirectURL": "",
          "content": {
            "size": 199,
            "mimeType": "application/json",
            "text": "{\"message\":\"Museum general entry ticket purchased\",\"ticketId\":\"382c0820-0530-4f4b-99af-13811ad0f17a\",\"ticketType\":\"general\",\"ticketDate\":\"2023-09-07\",\"confirmationCode\":\"ticket-general-e5e5c6-dce78\"}",
            "compression": 0
          },
          "bodySize": 199,
          "headersSize": 3038
        },
        "pageref": "page_1"
      }

[DmitryAnansky]

From the description:
...."so capturing a login flow puts credentials in the file"...

Actually, the HAR is passed through conditionallyMaskSecrets before being written

[ariesclark]

@ariesclark Could you please clarify what you mean by “never contained the request body”? Below is an example of a HAR log entry for a POST request. It contains both the request (including the request body) and the response.

If I understand correctly, the main issue is that the postData field is missing. Is that right?

Yup, that's right, postData is the only thing missing. My follow up PR for the coverage command depends on knowing each bodies weren't sent for testing, and depends on this change.

[DmitryAnansky]

Hi @ariesclark,
Will you have time to review or apply the suggested changes, or should we address them in your PR?

[Copilot]

Pull request overview

This PR fixes HAR capture for respect --har-output so request bodies are recorded in the HAR request.postData field (instead of always {}), enabling downstream tools like drift to validate request bodies rather than treating missing data as a pass.

Changes:

• Add buildPostData() to serialize text request bodies and derive mimeType from the request content-type header.
• Wire postData (and request.bodySize based on serialized text length) into the HAR entry produced by withHar.
• Add unit tests for buildPostData and a changeset documenting the fix.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
packages/cli/src/commands/respect/har-logs/with-har.ts	Uses buildPostData() and populates request.bodySize/request.postData in HAR entries.
packages/cli/src/commands/respect/har-logs/helpers/build-post-data.ts	New helper to produce HAR postData for string/URLSearchParams bodies and determine mimeType.
packages/cli/src/tests/commands/respect/har-logs/helpers/build-post-data.test.ts	New unit tests covering header shapes, fallbacks, and omitted non-text bodies.
.changeset/respect-har-post-data.md	Patch changeset describing the HAR postData fix for @redocly/cli.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit a927ba4. Configure here.}

[github-actions]

Performance Benchmark (Lower is Faster)

CLI Version	Bundle	Lint	Check Config
cli-latest	▓ 1.00x (Fastest)	▓ 1.00x ± 0.01	▓ 1.00x (Fastest)
cli-next	▓ 1.00x ± 0.01	▓ 1.00x (Fastest)	▓ 1.00x ± 0.01