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
I recently noticed an issue with HTTPZ's HTTPS downgrade detection: it just plain doesn't seem to work when dealing with IPFS local gateway redirects.
The issue seems to stem from the fact that HTTPZ can't accept wildcard hostname expansions, which would be required to make a proper manual exclusion (since the IPFS Companion redirects all IPFS resources to either .ipfs.localhost:8080 or .ipns.localhost:8080). I have tested that indeed if I put the precise hostname, it of course works, but this isn't really feasible for each and every IPFS resource...
I'm a bit surprised though that it doesn't try to downgrade to HTTP automatically once it sees that it can't connect via HTTPS, if I understood correctly the basic functionality and am not completely blind, I thought it would 😅
The text was updated successfully, but these errors were encountered:
Hello all,
I recently noticed an issue with HTTPZ's HTTPS downgrade detection: it just plain doesn't seem to work when dealing with IPFS local gateway redirects.
The issue seems to stem from the fact that HTTPZ can't accept wildcard hostname expansions, which would be required to make a proper manual exclusion (since the IPFS Companion redirects all IPFS resources to either .ipfs.localhost:8080 or .ipns.localhost:8080). I have tested that indeed if I put the precise hostname, it of course works, but this isn't really feasible for each and every IPFS resource...
I'm a bit surprised though that it doesn't try to downgrade to HTTP automatically once it sees that it can't connect via HTTPS, if I understood correctly the basic functionality and am not completely blind, I thought it would 😅
The text was updated successfully, but these errors were encountered: