-
Notifications
You must be signed in to change notification settings - Fork 4.4k
Description
Version
1.50.1
Steps to reproduce
- Clone https://github.com/mmacvicar/playwright-issue-report
- make check-etc-hosts
- make run
Expected behavior
Playwright should be able to reach a domain thorugh the proxy, regardless of any client certificates configuration. Particularly if they are unrelated to that domain.
Actual behavior
If any client certificates configuration is used. Playwright will fail to open or wrongly infer the protocol for any domain which is only available through a proxy. There are at least 3 scenarios to consider:
- Playwright can resolve the domain but it is unroutable (i.e behind a VPN, another network, only possible through the proxy). In this case, it will timeout as it tries to do ALPN without using the proxy (ALPNCache at
playwright/packages/playwright-core/src/server/socksClientCertificatesInterceptor.ts
Line 42 in bb8e914
class ALPNCache { - Playwright cannot even resolve th edomain. In this case, ALPN will fail fast and wrongly assume the protocol as http 1.1.
- A server might require a client certificate to finish the handshake, this would also make ALPN fail fast and assume http 1.1. I did not look at all at this.
Additional context
The correct behavir would be for ALPNCache to use both the proxy agent and the already created secure context to establish the TLS connection. I think @mxschmitt has a lot of context as he has been adding client certificates and later proxy support (thanks a lot).
I can fix this if this solution makes sense.
Environment
System:
OS: Linux 6.13 Arch Linux
CPU: (14) x64 Intel(R) Core(TM) Ultra 7 165U
Memory: 47.72 GB / 62.25 GB
Container: Yes
Binaries:
Node: 22.9.0 - ~/.nvm/versions/node/v22.9.0/bin/node
npm: 10.8.3 - ~/.nvm/versions/node/v22.9.0/bin/npm
pnpm: 9.13.1 - ~/.nvm/versions/node/v22.9.0/bin/pnpm
bun: 1.1.38 - ~/.bun/bin/bun
Languages:
Bash: 5.2.37 - /usr/bin/bash