node:http: split #2013 argument-validation parity tail

[andrewtdiz]

Summary

Split from #2013 after the fs validation reconciliation. The broad #2013 tracker named http as a historical stdlib argument-validation cluster. Existing open HTTP issues cover missing helper/export surface (#2519, #3712) and other HTTP behavior, but there was no focused child that owns Node-shaped validation errors for the claimed HTTP surface.

This issue tracks the HTTP validation remainder so #2013 can link to a precise module child instead of carrying an unsplit http backlog.

Related but separate

• node:http: expose top-level validation helpers and module properties #2519 tracks top-level validation helpers and module properties such as validateHeaderName, validateHeaderValue, globalAgent, and maxHeaderSize.
• node:http: module helper export tail is missing from manifest and parity coverage #3712 tracks a broader HTTP helper/export tail.
• node:http/https: ~50 byte-level response/header output diffs (status-line, default headers, body framing) #2132 and neighboring HTTP issues track byte-level response/server behavior, not the validation theme from stdlib doesn't throw Node arg-validation errors (ERR_INVALID_ARG_TYPE/EBADF/...) on bad input — ~85 tests across fs/buffer/net/http/crypto/zlib/process #2013.

Local scope signals

Current curated HTTP fixtures live under:

• test-parity/node-suite/http/server/
• test-parity/node-suite/http/agent/

Generated inventory also has test-files/test_parity_http.ts, which probes module-level helper and property surface that should validate arguments like Node once claimed.

Scope

Validate and, where needed, fix Node-compatible validation for deterministic node:http entry points in the supported surface, including:

• http.validateHeaderName(name[, label]) and http.validateHeaderValue(name, value) once exposed;
• http.request() / http.get() option and callback argument shapes for covered cases;
• http.createServer() listener/options validation for covered cases;
• Agent constructor/options and request creation validation where the curated suite exercises them;
• parser/proxy helper argument validation if those helpers are claimed in the manifest.

Match Node's thrown error class and .code where covered, such as ERR_INVALID_ARG_TYPE, ERR_INVALID_ARG_VALUE, and HTTP header validation codes.

Acceptance

• ./run_parity_tests.sh --suite node-suite --module http has no validation output mismatches, or any remaining validation failures are split by exact fixture/API.
• Top-level helper validation is either fixed here or clearly remains with node:http: expose top-level validation helpers and module properties #2519/node:http: module helper export tail is missing from manifest and parity coverage #3712 when those helpers are still unimplemented.
• Known failures and parity docs stop using stdlib doesn't throw Node arg-validation errors (ERR_INVALID_ARG_TYPE/EBADF/...) on bad input — ~85 tests across fs/buffer/net/http/crypto/zlib/process #2013 as the only HTTP validation tracker.
• stdlib doesn't throw Node arg-validation errors (ERR_INVALID_ARG_TYPE/EBADF/...) on bad input — ~85 tests across fs/buffer/net/http/crypto/zlib/process #2013 can reference this as the precise node:http validation child.

[proggeramlug]

Assessment (v0.5.1060): ./run_parity_tests.sh --suite node-suite --module http currently has 10 failures, all compile errors (not plain arg-validation) — these are deeper feature gaps, recommend splitting into narrower issues:

agent/request-create-connection, agent/request-create-socket,
agent/socket-event-introspection, incoming-message/client-set-encoding,
incoming-message/server-headers-body, server/add-trailers,
server/aliased-create-server, server/default-connection-headers,
server/timeout-knobs, server/upgrade-websocket

(server/upgrade-websocket overlaps #3891.) The arg-validation/error-shape portion isn't separable from these compile-level gaps yet.

[andrewtdiz]

Taking a narrow current-main HTTP compile/linking cut here. Current node-suite --module http has 14 compile failures where codegen emits external HTTP FFI symbols but optimized linking does not consistently pull the owning HTTP extension libraries. Scope for this cut: register the missing emitted js_http_* / js_node_http_* symbols in the external owner registry and add focused coverage for that ownership mapping. I am intentionally not taking the broader HTTP validation/body framing/API behavior work in this PR.

[andrewtdiz]

Opened draft PR #4216 for the HTTP external-symbol compile/linking cut: #4216

Scope: register the emitted HTTP/server response symbols with the http well-known owner, register the HTTP agent socket listener helpers with the net owner, keep well-known prebuilt wrapper resolution active under PERRY_NO_AUTO_OPTIMIZE=1, and force-retain the newer HTTP server symbols in libperry_ext_http.a.

Validation on the rebased branch with Node v26.3.0:

• cargo fmt --all -- --check
• cargo test -p perry-codegen emitted_http_suite_external_symbols_route_to_owners -- --nocapture
• cargo build --release --quiet -p perry -p perry-runtime -p perry-stdlib -p perry-ext-http -p perry-ext-net
• git diff --check
• ./scripts/check_file_size.sh
• PERRY_NO_AUTO_OPTIMIZE=1 ./run_parity_tests.sh --suite node-suite --module http: 5 pass / 12 parity fail / 0 compile fail / 0 skipped, report test-parity/reports/parity_report_20260603_055225.json

The remaining HTTP failures in that sweep are behavior/output mismatches, not compile/link failures.

[andrewtdiz]

Taking a follow-up HTTP compile/linking cut on current main. Fresh PERRY_NO_AUTO_OPTIMIZE=1 ./run_parity_tests.sh --suite node-suite --module http still has 14 compile failures, all link errors for emitted js_node_http_* / js_http_* / js_net_socket_* symbols. The registry already records those owners; the missing piece is that the no-auto-optimize path returns an empty well-known archive list instead of resolving the prebuilt perry-ext-http / perry-ext-net wrappers. Scope: make no-auto links honor the augmented well-known imports and add focused coverage for that link selection path. I am not taking HTTP response/body behavior or validation semantics in this PR.

[andrewtdiz]

Opened draft PR #4242 for this follow-up: #4242

Scope is the no-auto compile/link tail only. The fix keeps --no-auto-optimize / PERRY_NO_AUTO_OPTIMIZE=1 from dropping prebuilt well-known wrapper archives after codegen records HTTP/net/ws-owned FFI symbols, and adds focused coverage for that resolver path plus the HTTP upgrade WebSocket helper owner entries.

Validation summary:

• Before this cut, PERRY_NO_AUTO_OPTIMIZE=1 ./run_parity_tests.sh --suite node-suite --module http on current main reported 14 compile failures.
• With the PR branch and Node v26.3.0, the same full HTTP module run reports Parity Pass: 5, Parity Fail: 12, Compile Fail: 0, Skipped: 0.
• The remaining failures are HTTP runtime/output mismatches and are intentionally left for later behavior cuts.

[andrewtdiz]

This HTTP validation child now looks stale-open.

Later current-main HTTP validation from commit 5d8c9417d reports the full normal node-suite --module http run green:

Parity Pass:   17
Parity Fail:   0
Compile Fail:  0
Node Fail:     0
Report: test-parity/reports/parity_report_20260603_144834.json

That run supersedes the earlier no-auto compile/linking reports in this thread. The remaining historical no-auto output mismatches were not a live argument-validation tail after the later HTTP reconciliation. This issue looks ready for maintainer closure under the #2013 validation umbrella.

[andrewtdiz]

Claiming a current-main HTTP no-auto linking slice.

On origin/main 8576ca3, PATH="/root/.npm/_npx/bac97da9607b7ef2/node_modules/node/bin:$PATH" PERRY_NO_AUTO_OPTIMIZE=1 ./run_parity_tests.sh --suite node-suite --module http reports 3 pass, 14 compile failures (test-parity/reports/parity_report_20260604_083856.json). The failures share undefined js_node_http_* / js_http_request_overload symbols at link time, e.g. js_node_http_create_server_with_options, js_node_http_server_listen, js_node_http_res_end, and HTTP server timeout accessors.

This looks like the HTTP extension archive is not being linked for no-auto parity, not a per-fixture behavior mismatch. I do not see an active PR for this HTTP link gap; #4277/#4275 are http2-specific.