Skip to content

Tests: serve the network tests from a loopback HTTP server - #249

Open
matthargett wants to merge 2 commits into
BabylonJS:mainfrom
rebeckerspecialties:tests-local-http-server
Open

matthargett wants to merge 2 commits into
BabylonJS:mainfrom
rebeckerspecialties:tests-local-http-server

Conversation

@matthargett

@matthargett matthargett commented Sep 16, 2026

Copy link
Copy Markdown

Problem

The XMLHttpRequest and fetch suites hit https://github.com/ and raw.githubusercontent.com to check status codes, statusText, percent-encoding of non-ASCII paths and abort-in-flight behaviour. Any hiccup on those hosts fails the run — the recent upstream reruns of #116 went red on external 504s (httpbin.org, github.com) with the same commit green elsewhere — and a runner without outbound network cannot run the suite at all.

Change

The test host starts a small loopback HTTP/1.1 server (Tests/UnitTests/Shared/TestHttpServer.{h,cpp}, plain sockets, Winsock on Windows) on 127.0.0.1 with an ephemeral port and hands its origin to the scripts as the hostTestServer global. Routes, matched after percent-decoding the request-target:

path response
/ 200 OK
/assets/<name> 200 only when <name> decodes to στρογγυλεμένος % κύβος.glb — the client's own encoding is what gets exercised; anything else 404
/delay/<ms> 200 after the delay, so the abort tests always abort a request that is genuinely in flight
anything else 404 Not Found

Every response is text/plain with Connection: close. tests.ts keeps its assertions and just takes the URLs from a testServer table; the connection-refused tests still use 127.0.0.1:1. The Android test library (UnitTestsJNI) links the server too. No polyfill code changes.

Verified on macOS (JavaScriptCore): 225 passing / 3 pending in the JavaScript suite, UnitTests 23/23. Fork twin: rebeckerspecialties#33.

The XMLHttpRequest and fetch suites fetched https://github.com/ and a
mesh from raw.githubusercontent.com to check status codes, statusText,
percent-encoding of non-ASCII paths and abort-in-flight. Any hiccup on
those hosts (or a runner without outbound network) failed the run, as
the 504s on the recent upstream reruns showed.

The test host now starts a small HTTP/1.1 server on 127.0.0.1 with an
ephemeral port and publishes its origin to the scripts as the
`hostTestServer` global. It answers "/" with 200, unknown paths with
404 "Not Found", "/assets/<name>" with 200 only when the request-target
decodes to the expected UTF-8 file name (so the client's own encoding
is what gets checked), and "/delay/<ms>" after a delay so the abort
tests are guaranteed to abort a request that is still in flight. The
connection-refused tests keep using 127.0.0.1:1.

Plain sockets on every platform (Winsock on Windows, poll-driven accept
loop, MSG_NOSIGNAL/SO_NOSIGPIPE for clients that go away mid-request);
the Android test library links it too.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@matthargett

Copy link
Copy Markdown
Author

Fork twin caught the Android side: UrlLib there goes through HttpURLConnection, and with targetSdk 33 the platform blocks cleartext http://127.0.0.1 unless the app opts in, so the loopback requests failed as transport errors (fetch failed, status 0). Added android:usesCleartextTraffic="true" to the test app's manifest (2d32a1d); the rest of the matrix was already green.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants