fetch-based networking follow-ups

[copy]

• Doesn't work on https (running curl copy.sh in buildroot):

Mixed Content: The page at 'https://copy.sh/v86/?profile=buildroot' was loaded over HTTPS, but requested an insecure resource 'http://copy.sh/'. This request has been blocked; the content must be served over HTTPS.

• In the arch profile, dhcp seems to have an issue:

root@localhost:~# ./networking.sh 
dhcpcd-9.4.1 starting
DUID 00:01:00:01:2e:34:fb:88:00:22:15:58:de:2b
eth0: IAID 15:58:de:2b
eth0: soliciting a DHCP lease
eth0: offered 192.168.86.100 from 192.168.86.1
eth0: probing address 192.168.86.100/24
eth0: 52:54:00:01:02:03(52:54:00:01:02:03) claims 192.168.86.100
eth0: DAD detected 192.168.86.100
eth0: soliciting a DHCP lease
eth0: offered 192.168.86.100 from 192.168.86.1
eth0: probing address 192.168.86.100/24
eth0: 52:54:00:01:02:03(52:54:00:01:02:03) claims 192.168.86.100
eth0: DAD detected 192.168.86.100
eth0: soliciting a DHCP lease
eth0: offered 192.168.86.100 from 192.168.86.1
eth0: probing address 192.168.86.100/24
eth0: 52:54:00:01:02:03(52:54:00:01:02:03) claims 192.168.86.100
eth0: DAD detected 192.168.86.100
...

• write some docs, in particular mention chromium --user-data-dir=/tmp/temp-chromium-profile --disable-web-security
• make corsproxy/masquerade, etc. configurable in the V86 constructor and in the UI

[SuperMaxusa]

• Doesn't work on https (running curl copy.sh in buildroot):

On Firefox with HTTPS-Only mode it just automatically upgrades to HTTPS and works without problems:

Anyways, I think we could make a force changing protocol for fetch() if page with emulator was opened over HTTPS:

--- a/src/browser/fetch_network.js
+++ b/src/browser/fetch_network.js
@@ -1174,6 +1174,9 @@ TCPConnection.prototype.on_data_http = async function(data) {
         if(/^https?:/.test(first_line[1])) {
             target = new URL(first_line[1]);
         }
+        if(target.protocol === "http:" && window.location.protocol === "https:") {
+            target.protocol = "https:";
+        }    
         let req_headers = new Headers();
         for(let i = 1; i < headers.length; ++i) {
             let parts = headers[i].split(": ");

With this patch, curl httpbin.org works (on current https://copy.sh/v86/?profile=buildroot&networking_proxy=fetch fails).

UPD: You can allow mixed content in Chrome: https://superuser.com/a/1652795, curl copy.sh doesn't work because CORS, but curl theoldnet.com works properly (via http).

[ProgrammerIn-wonderland]

• Doesn't work on https (running curl copy.sh in buildroot):

Mixed Content: The page at 'https://copy.sh/v86/?profile=buildroot' was loaded over HTTPS, but requested an insecure resource 'http://copy.sh/'. This request has been blocked; the content must be served over HTTPS.

• In the arch profile, dhcp seems to have an issue:

root@localhost:~# ./networking.sh 
dhcpcd-9.4.1 starting
DUID 00:01:00:01:2e:34:fb:88:00:22:15:58:de:2b
eth0: IAID 15:58:de:2b
eth0: soliciting a DHCP lease
eth0: offered 192.168.86.100 from 192.168.86.1
eth0: probing address 192.168.86.100/24
eth0: 52:54:00:01:02:03(52:54:00:01:02:03) claims 192.168.86.100
eth0: DAD detected 192.168.86.100
eth0: soliciting a DHCP lease
eth0: offered 192.168.86.100 from 192.168.86.1
eth0: probing address 192.168.86.100/24
eth0: 52:54:00:01:02:03(52:54:00:01:02:03) claims 192.168.86.100
eth0: DAD detected 192.168.86.100
eth0: soliciting a DHCP lease
eth0: offered 192.168.86.100 from 192.168.86.1
eth0: probing address 192.168.86.100/24
eth0: 52:54:00:01:02:03(52:54:00:01:02:03) claims 192.168.86.100
eth0: DAD detected 192.168.86.100
...

• write some docs, in particular mention chromium --user-data-dir=/tmp/temp-chromium-profile --disable-web-security
• make corsproxy/masquerade, etc. configurable in the V86 constructor and in the UI

I actually was having the dhcp issue on a custom built alpine issue as well, dhcpcd. Ended up just using a static IP :/

[ProgrammerIn-wonderland]

wanted to mention that the issue also seems to happen on windows dhcp, it seems like the only working client is udhcpc, dhcpcd and windows dhcp don't work

[ProgrammerIn-wonderland]

figured it out, @copy dhcpcd sends an ARP to see if 192.168.1.100 belongs to someone before claiming it (DAD stands for Duplicate Address Detection), if you run dhcpcd with --noarp it seems to work fine.. I'm wondering what a good fix for this would be

[ProgrammerIn-wonderland]

fixed the issue in my PR by responding that the requestor already owns the IP on the arp, dhcpcd seems to be fine with that