sz-chrome-remote-cdp.git/castle-search/test/resolve.test.ts, branch masterpi-browser-harness, patched to drive a Chrome on another host over CDP, with castle_cdp_search web search
https://git.soarez.net/sz/sz-chrome-remote-cdp.git/atom?h=master2026-11-06T03:33:30+00:00castle-search: resolve Google links lazily, in Chrome, not eagerly over plain HTTP2026-11-06T03:33:30+00:00Igor Soarezigor@soarez.org2026-11-06T03:33:30+00:00urn:sha1:561f0ee076c684a79fd5671af1bad0894f33e4de
The Node-side resolver sent one curl-like request per result with no
cookies, JS or browser; Google answers that with its 'Verifying your
request' countdown after a handful, and the testing itself triggered it.
A click or direct navigation in Chrome redirects at once (measured).
Search now leaves Google links wrapped and prints the breadcrumb Google
shows for each. castle_cdp_resolve follows one wrapped link in a Chrome tab
when the agent picks it, accepts only google.com/goto?url=<token>, and
reports the verification page instead of waiting it out.
castle-search: read Google results again by resolving its /goto links2026-11-06T03:17:16+00:00Igor Soarezigor@soarez.org2026-11-06T03:17:13+00:00urn:sha1:74ff9fdcb8b49a021b63ac2e6b0191e29754d0f3
Google now wraps every result as google.com/goto?url=<opaque token>. The
self-host filter discarded all of them, so every Google search failed with
'nothing could be parsed'. Accept /goto, resolve it node-side from the
302 Location, and when Google answers its 'Verifying your request'
interstitial instead, keep the wrapped link and put the displayed
breadcrumb in the snippet.