[Bug]: Protocol with "standard" privilege refuse to load an URL with a hexadecimal number as host
nand2 opened this issue · 3 comments
Preflight Checklist
- I have read the Contributing Guidelines for this project.
- I agree to follow the Code of Conduct that this project adheres to.
- I have searched the issue tracker for a bug report that matches the one I want to file, without success.
Electron Version
24.0.0
What operating system are you using?
Ubuntu
Operating System Version
Linux nand-MS-7C95 5.15.0-67-generic #74~20.04.1-Ubuntu SMP Wed Feb 22 14:52:34 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
What arch are you using?
x64
Last Known Working Electron version
No response
Expected Behavior
I register a web3:// protocol in "standard" privilege
protocol.registerSchemesAsPrivileged([
{ scheme: 'web3', privileges: { standard: true } }
])
protocol.registerStreamProtocol("web3", async (request, callback) => {
console.log('Web3 url handler called with URL: ' + request.url);
});
Then I try to load an URL with a 0x... hexadecimal host.
let browserView = new BrowserView();
browserView.webContents.on('did-fail-load', (e, errorCode, errorDescription) => {
console.log('did-fail-load', errorCode, errorDescription)
})
let url = "web3://0x1f9840a85d5af5bf1d1762f925bdaddc4201f984/";
browserView.webContents.loadURL(url);
Expected result in console :
Web3 url handler called with URL: web3://0x1f9840a85d5af5bf1d1762f925bdaddc4201f984/
Actual Behavior
Actual result in console :
did-fail-load -300 ERR_INVALID_URL
Testcase Gist URL
https://gist.github.com/nand2/79d957b168a9eb1184903cd98efc50ec
Additional Information
This fails if we set "standard" to true, and we try to load an URL with an 0x.... hexadecimal number as the host.
It looks like it is detecting the hexadecimal number and trying to parse it as an IP address.
I would need the "standard" mode as I want to access web storage API (localStorage, ...)
Thank you
This is not unfortunately a problem with Electron. The url you are using is invalid per Chromium's own URL wrapper. I recommend you just use something slightly different that doesn't have this issue.
Thank for you answer.
But what if there is no room for change, because these are part of URL specification of a new protocol that cannot be changed?
If I were to maintain my own fork for a while, what paths would you recommend? Disabling the .is_valid() URL checks?
Thank you
Bug report and candidate patch submitted at chromium : https://bugs.chromium.org/p/chromium/issues/detail?id=1441043