Native browser-mode transport resets on legacy HTTPS target; Node fallback can only work around it

[jippylong12]

Summary

The underlying issue is in the native browser-mode transport.

Against a legacy HTTPS target (https://nysdoccslookup.doccs.ny.gov/), the native transport fails immediately during request bootstrap with transport-level reset / send-request failures.

This issue is not just "the Node wrapper needs better retry logic". The wrapper can work around the problem, but the actual incompatibility appears to be in the native transport stack.

Related: #205

Affected layer

Native transport behavior:

• Rust / reqwest / hyper-based browser-mode request path

Not the main issue:

• JS wrapper redirect handling
• app-level scraper logic
• Apify actor integration

Expected behavior

A browser-mode Impit client should complete the initial request successfully against this target without requiring a wrapper-level compatibility transport.

Actual behavior

The native browser-mode request fails immediately on the initial request.

Representative failures included:

• SendRequest
• Connection reset by peer
• UnexpectedEof

Minimal reproduction

import { Impit } from "impit";

const impit = new Impit({
  browser: "chrome",
});

const response = await impit.fetch("https://nysdoccslookup.doccs.ny.gov/");
console.log(response.status);

Why this looks like a native-transport issue

I was able to make this target work only by adding a wrapper-level compatibility HTTP/1.1 fallback path in impit-node.

That proves the npm package can recover, but it does not prove the native transport is healthy. It points the other way:

• native browser-mode transport fails
• wrapper-level compatibility path succeeds

So the real bug remains in the native transport behavior.

Additional notes

I reproduced the same pattern for:

• homepage bootstrap GET
• follow-up search POST

For this target, the wrapper-level compatibility path succeeds for both requests while the native browser-mode path fails.

Environment

• impit@0.13.1
• Node.js 24.x
• macOS arm64
• also reproduced with proxied HTTPS requests

Scope of the related PR

I have a separate draft PR that improves vanillaFallback in the Node wrapper.

That PR should be read as:

• a practical compatibility workaround
• not a fix for the native browser-mode transport