copy
https requests
Im working on a solution for that -- https://github.com/basicer/v86/tree/tls
I created a Chrome extension that allows at least HTTP requests by bypassing CORS errors.
Im working on a solution for that -- https://github.com/basicer/v86/tree/tls
@basicer: This looks really intriguing! Does this assume the HTTP client in the guest to accept unknown self-signed (root) certificates? The HTTP server needs to be CORS-enabled I assume. I attempted to test your PR but failed, do you have some test instructions? Thanks!
I updated the branch and turned it into a PR.
In an alpine VM I can just do:
curl http://mitm.it/cert.pem >> /etc/ssl/certs/ca-certificates.crt
curl https://google.com
None of the current test images have anything that can make a TLS connection for the device test.
I updated the branch and turned it into a PR.
Yes I saw the PR, cloned and built it locally and looked through the diff.
In an alpine VM I can just do:
curl http://mitm.it/cert.pem >> /etc/ssl/certs/ca-certificates.crt curl https://google.com
Across different guest OSes I got the same error, curl fails to connect to server port 443.
What I was missing when building v86 was to also run:
make build/mitm.mjs
Otherwise mitm.mjs wasn't build and the dynamic import in fetch_network.js failed silently, thus never intercepting HTTPS requests to port 443 which explains the error.
Now your example works (Debian 12 VM), great!
am trying to build an application where I can create a course with a fixed command passed through a .sh script. After the command executes successfully, the terminal will be killed, and only a limited number of retries will be allowed.
And how does fetch mode come into play? Do you host a page with v86? Do you host the page that is being fetched via v86?
So without fetch, v86 is using a WebSocket connection, but I don’t want to add more complexity. Yep, I hosted it. So, I created a Chrome extension that allows HTTP requests.
I've been toying with the idea of using v86 in the yarnpkg.com website to support its tutorials and perhaps make it easier for users to share bug reproductions. Being able to rely on the fetch backend would be ideal, as the npm registries have CORS enabled.
I've been toying with the idea of using v86 in the yarnpkg.com website to support its tutorials and perhaps make it easier for users to share bug reproductions. Being able to rely on the fetch backend would be ideal, as the npm registries have CORS enabled.
~~A simple solution might be to add a HTTP/HTTPS mapping option based on domain names to the fetch backend.~~
~~Let's say we add a new fetch backend option https_domains, a string with a list of domain names like example.com foo.com bar.com, for example.~~
~~Now, if the fetch backend intercepts a HTTP request from the guest to one of these domains, it rewrites the URL for the call to fetch() from HTTP to HTTPS. So if the guest would make a request to http://example.com/path?query then we'd transparently fetch https://example.com/path?query.~~
~~I blieve this could suffice in your case because you define the URLs in the tutorials.~~
EDIT: This kind of URL-rewriting is already the default behaviour in the fetch backend if v86 is loaded using HTTPS and the guest makes a HTTP request.