-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
fetch-based networking follow-ups #1091
Comments
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 --- 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, UPD: You can allow mixed content in Chrome: https://superuser.com/a/1652795, |
I actually was having the dhcp issue on a custom built alpine issue as well, dhcpcd. Ended up just using a static IP :/ |
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 |
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 |
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 |
curl copy.sh
in buildroot):chromium --user-data-dir=/tmp/temp-chromium-profile --disable-web-security
The text was updated successfully, but these errors were encountered: