mshtml: Use the last colon in proxy url as port separator
Hi André,
http://domain\user:password(a)server.com:8080 makes it visible that it's intended to get the last colon
What about http://domain\user:password(a)server.com? password isn't the port number. --Juan
Am 17.08.2011 22:18, schrieb Juan Lang:
Hi André,
http://domain\user:password(a)server.com:8080 makes it visible that it's intended to get the last colon
What about http://domain\user:password(a)server.com? password isn't the port number. --Juan
in case password is not a number atoi would fail and everythings fine :) so yes, if password is a number we get in trouble, so we need a better check -- Best Regards, André Hentschel
On 08/17/2011 10:31 PM, André Hentschel wrote:
Am 17.08.2011 22:18, schrieb Juan Lang:
Hi André,
http://domain\user:password(a)server.com:8080 makes it visible that it's intended to get the last colon
What about http://domain\user:password(a)server.com? password isn't the port number. --Juan
in case password is not a number atoi would fail and everythings fine :) so yes, if password is a number we get in trouble, so we need a better check Is the ProxyServer specified as an URL? If yes then use the proper API to dissect the URL instead of cobbling something together.
bye michael
Is the ProxyServer specified as an URL? If yes then use the proper API to dissect the URL instead of cobbling something together.
Just to follow up in this idea, you could use InternetCrackUrl. mshtml delay loads wininet, but it also loads urlmon, which also loads wininet, so in effect wininet is always loaded and available. But a larger question is, why load the proxy settings from the registry only? If you query wininet for them instead, then the environment variable http_proxy is also checked. There was bug 5625 about this, which I set to fixed based on commit 80f02b82d68902f32578a7bcf6cfbaa715b724ce. I may have been mistaken. Under what circumstances is the network.proxy.http gecko setting still being used? Maybe for embedded content, e.g. IMG tags? If these were set by querying wininet instead, then at least we wouldn't have potentially different proxy settings for some HTTP requests than for others. --Juan
Am 18.08.2011 22:50, schrieb Juan Lang:
Is the ProxyServer specified as an URL? If yes then use the proper API to dissect the URL instead of cobbling something together.
Just to follow up in this idea, you could use InternetCrackUrl. mshtml delay loads wininet, but it also loads urlmon, which also loads wininet, so in effect wininet is always loaded and available.
But a larger question is, why load the proxy settings from the registry only? If you query wininet for them instead, then the environment variable http_proxy is also checked. There was bug 5625 about this, which I set to fixed based on commit 80f02b82d68902f32578a7bcf6cfbaa715b724ce. I may have been mistaken. Under what circumstances is the network.proxy.http gecko setting still being used? Maybe for embedded content, e.g. IMG tags? If these were set by querying wininet instead, then at least we wouldn't have potentially different proxy settings for some HTTP requests than for others. --Juan
just sent a patch doing that. I'm not sure for what winegecko uses it, but that function was added by intention and jacek already modified it a bit, so there must be a reason. -- Best Regards, André Hentschel
On 08/19/11 22:10, André Hentschel wrote:
Am 18.08.2011 22:50, schrieb Juan Lang:
Is the ProxyServer specified as an URL? If yes then use the proper API to dissect the URL instead of cobbling something together. Just to follow up in this idea, you could use InternetCrackUrl. mshtml delay loads wininet, but it also loads urlmon, which also loads wininet, so in effect wininet is always loaded and available.
But a larger question is, why load the proxy settings from the registry only? If you query wininet for them instead, then the environment variable http_proxy is also checked. There was bug 5625 about this, which I set to fixed based on commit 80f02b82d68902f32578a7bcf6cfbaa715b724ce. I may have been mistaken. Under what circumstances is the network.proxy.http gecko setting still being used? Maybe for embedded content, e.g. IMG tags? If these were set by querying wininet instead, then at least we wouldn't have potentially different proxy settings for some HTTP requests than for others. --Juan just sent a patch doing that. I'm not sure for what winegecko uses it, but that function was added by intention and jacek already modified it a bit, so there must be a reason.
set_proxy shouldn't be needed any more since we use urlmon for all connections. I didn't remove it immediately because it was relatively easy to restore the old behaviour for some time, but other pieces of the old code are already killed now and it's about the last piece left from before-urlmon times. Feel free to kill it. Cheers, Jacek
Am 22.08.2011 11:01, schrieb Jacek Caban:
On 08/19/11 22:10, André Hentschel wrote:
Am 18.08.2011 22:50, schrieb Juan Lang:
Is the ProxyServer specified as an URL? If yes then use the proper API to dissect the URL instead of cobbling something together. Just to follow up in this idea, you could use InternetCrackUrl. mshtml delay loads wininet, but it also loads urlmon, which also loads wininet, so in effect wininet is always loaded and available.
But a larger question is, why load the proxy settings from the registry only? If you query wininet for them instead, then the environment variable http_proxy is also checked. There was bug 5625 about this, which I set to fixed based on commit 80f02b82d68902f32578a7bcf6cfbaa715b724ce. I may have been mistaken. Under what circumstances is the network.proxy.http gecko setting still being used? Maybe for embedded content, e.g. IMG tags? If these were set by querying wininet instead, then at least we wouldn't have potentially different proxy settings for some HTTP requests than for others. --Juan just sent a patch doing that. I'm not sure for what winegecko uses it, but that function was added by intention and jacek already modified it a bit, so there must be a reason.
set_proxy shouldn't be needed any more since we use urlmon for all connections. I didn't remove it immediately because it was relatively easy to restore the old behaviour for some time, but other pieces of the old code are already killed now and it's about the last piece left from before-urlmon times. Feel free to kill it.
Cheers, Jacek
ok, just sent a patch. Still my previous attempt showed another wine bug and i'll try to follow it with tests and fix it. (size query per InternetQueryOption) -- Best Regards, André Hentschel
participants (4)
-
André Hentschel -
Jacek Caban -
Juan Lang -
Michael Stefaniuc