You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
manage browser process directly, auto-detect lightpanda or chrome
Replace chromedp.NewExecAllocator with our own os/exec launch so exec
mode works for both chrome and lightpanda. resolveBrowser searches PATH
lightpanda-first, then chrome variants; explicit exec <path> wins and
the kind is inferred from the basename. Lightpanda is started as
'lightpanda serve --host 127.0.0.1 --port <picked>'; chrome gets the
default flag set + a temp --user-data-dir + --remote-debugging-port.
waitForBrowser polls /json/version until ready. Cleanup sends SIGINT
(5 s grace, then SIGKILL) and removes the temp dir.
Copy file name to clipboardExpand all lines: README.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -55,17 +55,17 @@ chrome {
55
55
-`timeout` - maximum time to wait for Chrome to render the page, default is `10s`.
56
56
-`mime_types` - list of MIME types to render, default is `text/html`.
57
57
- Browser (only one of these):
58
-
-`exec` - executes the local browser binary by given path, if the first argument starts with a dash (`-`), the binary is automatically found in the path and all the arguments are treated as additional flags on top of the [default flags](https://pkg.go.dev/github.com/chromedp/chromedp#pkg-variables)
59
-
-`exec_no_default_flags` - the same as `exec` but without the default flags
58
+
-`exec` - the middleware launches a browser process itself and connects to it. If a path is given, that binary is used; otherwise PATH is searched: **lightpanda first, then chrome variants** (`google-chrome`, `google-chrome-stable`, `chromium`, `chromium-browser`, plus `/Applications/Google Chrome.app/...` and `/Applications/Chromium.app/...` on macOS). For chrome-kind binaries a sensible default flag set is applied; for lightpanda the middleware runs it as `lightpanda serve --host 127.0.0.1 --port <picked>`. Extra flags after `--` are appended to the launch command. The browser kind is inferred from the binary basename (anything containing "lightpanda" → lightpanda mode).
59
+
-`exec_no_default_flags` - the same as `exec` but without the default chrome flags (no effect for lightpanda)
60
60
-`url` - URL to the debugging protocol endpoint of a remote browser instance
61
61
-`fullfill_hosts` - a list of hosts to issue as internal requests through the webserver, there's automatically the host of the original request
62
62
-`continue_hosts` - a list of hosts to let Chrome do the regular network requests
63
63
64
-
Every render opens a fresh CDP WebSocket to the browser. For `exec` mode the middleware launches the browser once on a known port and connects to it per request; for `url` mode it opens a new WS per request to the configured remote endpoint. This avoids the per-request `Target.createBrowserContext` round-trips on a shared connection (faster on Chrome) and gives Lightpanda 0.2.4+ a separate browser per connection (true concurrency).
64
+
Every render opens a fresh CDP WebSocket to the browser. For `exec` mode the middleware launches the browser once on a known port (managed via `os/exec`, not chromedp's allocator, so both chrome and lightpanda are supported) and connects to it per request; for `url` mode it opens a new WS per request to the configured remote endpoint. This avoids the per-request `Target.createBrowserContext` round-trips on a shared connection (faster on Chrome) and gives Lightpanda 0.2.4+ a separate browser per connection (true concurrency).
65
65
66
66
## Browsers
67
67
68
-
In addition to headless Chrome, [Lightpanda](https://lightpanda.io/) is supported as a CDP-compatible backend. Start it as `lightpanda serve --host 127.0.0.1 --port 9222` and point caddy-chrome at it via `url http://127.0.0.1:9222/`. Lightpanda is detected automatically (via `/json/version`) and the middleware switches to a single-target rendering mode:
68
+
In addition to headless Chrome, [Lightpanda](https://lightpanda.io/) is supported as a CDP-compatible backend. The simplest setup is `exec` with no path — if `lightpanda` is in PATH it'll be picked over chrome and the middleware launches `lightpanda serve` itself. Alternatively, run it externally as `lightpanda serve --host 127.0.0.1 --port 9222` and point caddy-chrome at it via `url http://127.0.0.1:9222/`. Lightpanda is detected automatically (via `/json/version`) and the middleware switches to a single-target rendering mode:
69
69
70
70
- as for Chrome, every render opens a fresh CDP WebSocket — Lightpanda 0.2.4+ gives each connection its own full browser, so concurrent requests render in parallel;
71
71
-`Fetch` interception is skipped — Lightpanda's CDP processes commands serially per session, and dispatching `Fetch.fulfillRequest`/`continueRequest` for a sub-resource while the navigation fulfillment is being parsed deadlocks the WS read loop (see [lightpanda-io/browser#2391](https://github.com/lightpanda-io/browser/issues/2391)). Instead, caddy-chrome sets a `X-Caddy-Chrome-Bypass` header via `Network.setExtraHTTPHeaders` and lets Lightpanda fetch the navigation and every sub-resource (XHR, `fetch()`, `<script>`) directly from the same Caddy server. The middleware sees the marker header and passes the request straight to the next handler;
0 commit comments