Unless we find out a different way for the following set of automated steps:

• limit per-proxy parallel limit to 1 (or leave as is? I'd rather avoid races, tho)
• config an http (1.1) plain proxy on the client
• connect https://blocked.com/foo:
  • send CONNECT blocked.com to "a proxy" (httpd.js handler)
  • [1] return 403 + Connection: keep-alive and actually keep the connection alive
  • ignore w/o any answer any other requests and keep the connection alive (behave in a broken way, actually)
    EXPECTED (but impossible to test in the client side test): the connection to the proxy is closed
• connect https://okgo.com/foo:
  • send CONNECT okgo.com
  • return 200 OK
  • forward to ssltunnel and handle the request normally (let httpd handler behind the sslproxy return 200 OK+test content)
    EXPECTED: get the test content response immediately
    UNEXPECTED: test times out

We could potentially implement [1] via seize response, so the dependency on 469228 is tentative only.