-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Playwright routeFromHAR functionality doesn't work with gzip compressed content #34514
Comments
Where did the HAR file come from? It doesn't appear to have come from Playwright. Due to looseness of the spec and other implementations, we can only guarantee support of HAR files generated by Playwright. Playwright explicitly decompresses the responses it stores on disk, so they're never gziped. |
@agg23 I wrote the HAR file. I see. The HAR file I generated is pretty "standard", its just serving a file. It works in Playwright when I don't |
The HAR support works the same way as
Why do you want to serve |
The JS we're serving to the browser is quite large and it seems like Playwright is crashing when we serve the uncompressed JS via the HAR file. Also, when we compress the JS, the browser will cache the asset. When it's not compressed, we've noticed that the browser does not cache the asset. The caching is important to us because it means that tests will execute faster because they load the Javascript faster. |
It appears this might be a limitation in CDP, does that sound right to you? https://chromedevtools.github.io/devtools-protocol/tot/Fetch/#method-fulfillRequest The |
It is likely a CDP limitation, yes. Can you give us more context on your workflow and what you're trying to accomplish? We're very curious about how Playwright might better serve you. How large of files are you trying to serve? If you're serving a large scenario and would like to rely on caching, why not spin up your own simple server to serve those assets? Playwright disables browser caching for routes so they are actually re-evaluated properly on each request. Since you cannot serve compressed files through this, you haven't seen it, but those |
I think spinning up our own simple server will be the approach we take given the limitations. We were trying to use Playwright APIs instead since they were easily accessible. The nice thing about Playwright's network APIs is that it allows you to override server-side behavior at the same URLs that the frontend reaches out to, without having to change the URL that the frontend reaches out to. With the simple server solution, we'll have to adjust the URL that our frontend reaches out to. It's ok, just not ideal. |
Version
1.50.0
Steps to reproduce
In this minimally reproducible example, Playwright is serving a gzip compressed javascript file to the browser using the
routeFromHAR
functionality. The browser, however, is unable to execute the javascript.Steps to reproduce:
npm i
to install dependenciesnode index.js
and notice that he browser logs an "Unexpected syntax error" vs. executing the Javscript inweb.js
Expected behavior
I expect the browser to be able to execute the Javascript
Actual behavior
The browser is console logging "Unexpected syntax error" instead of executing the Javascript
Additional context
No response
Environment
System: OS: macOS 14.3 CPU: (10) arm64 Apple M1 Max Memory: 2.80 GB / 64.00 GB Binaries: Node: 22.10.0 - /usr/local/bin/node npm: 10.9.0 - /usr/local/bin/npm pnpm: 8.15.1 - /usr/local/bin/pnpm IDEs: VSCode: 1.95.3 - /opt/homebrew/bin/code Languages: Bash: 3.2.57 - /bin/bash npmPackages: playwright: ^1.50.0 => 1.50.0
The text was updated successfully, but these errors were encountered: