[Development] QtNetwork: using system proxy by default

[shane.kearns at accenture.com]

Apparently not, I don't know why Microsoft implemented it this way.
The result is only cached if a PAC script is successfully downloaded.

The DHCP method doesn't serve the PAC url together with the IP address, it's a separate query sent to the DHCP server by the browser (or us)

If autodetection fails, it returns "no proxy" for this request, but tries autodetection again next time the API is called.

The autodetection procedure looks like this pseudocode (but is all one API call to us):
for(tries=0;tries<2;tries++) {
    send(DHCP_INFORM requesting option 252);
    if (wait_for_response(6 seconds)) {
        pac_url = response;
        break;
    }
}
if(!pac_url) {
    pac_url = "http://wpad/wpad.dat";
}

When using the windows API, we can enable either DNS, DHCP or both.
Using DNS only would be faster, but may not work for some users if their office network used DHCP only deployment.

Also, I checked today and it looks like Chromium have now implemented DHCP autodetection by themselves as well. They are checking it on startup & caching the results.
________________________________________
From: Knoll Lars [Lars.Knoll at digia.com]
Sent: 15 October 2012 16:00
To: Kearns, Shane
Cc: <development at qt-project.org>
Subject: Re: [Development] QtNetwork: using system proxy by default

Hi Shane,

(adding the ML back in again…)

wouldn't Windows run the DHCP detection only once at startup (or when network status changes) and cache the result? Why would we need to re-run this inside the Qt app?

Cheers,
Lars

On Oct 15, 2012, at 4:00 PM, shane.kearns at accenture.com wrote:

> Hi Lars,
>
> It happens the first time only (because we have a workaround to disable autodetection if it fails)
> When I reproduced it, it was 12 seconds.
>
> The problem is windows sends a DHCP packet with a microsoft extension, and has a long timeout waiting for a reply.
> With good DHCP servers, they'll reply (negatively if they don't support that extension)
> With bad DHCP servers, there is no reply which triggers the problem.
>
> It seems like some wireless access points/home routers have a "bad" or incomplete DHCP implementation
>
> I agree that enabling system proxy by default is what most app developers would want.
> An option would be to always disable DHCP detection, which gets rid of this worst case.
> ________________________________________
> From: Knoll Lars [Lars.Knoll at digia.com]
> Sent: 15 October 2012 08:39
> To: Kearns, Shane
> Subject: Re: [Development] QtNetwork: using system proxy by default
>
> I'd agree with Simon that #4 would be the best default option from a user experience point of view. Most likely it's also what most app developers want.
>
> Is the windows problem purely something happening once when initiating the first connection, or does it happen with every connection? And what does this mean in a real use case (ie. how many seconds are we talking about)?
>
> Cheers,
> Lars
>
> On Oct 11, 2012, at 4:34 PM, shane.kearns at accenture.com wrote:
>
>>> IMHO #4 gives the best out-of-the-box experience.
>>>
>>> Is there a way to do the blocking winapi call in a thread on app start-
>>> up maybe?
>>
>> Doesn't help if the first thing an application wants to do is download something from the network.
>> It would only help because of the workaround we already have to disable WPAD if it fails (which is not ideal if you start an app at home, then take your laptop to work)
>>
>>> How do other apps (i.e. Chrome) handle this without blocking the user
>>> experience?
>>
>> Chrome doesn't use the windows API, they make a request to "http://wpad" and interpret the pac script themselves.
>> Firefox is slow to load pages, but UI is not blocked (which points to using the windows API in a thread)
>>
>> WPAD is inherently spoofable, but the Chrome method is worse than the windows API, as you can't tell if the name came from DNS or multicast name resolution.
>> In any case, we don't have a javascript interpreter available at the QtNetwork level.
>>
>> Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy.
>> ______________________________________________________________________________________
>>
>> www.accenture.com
>>
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
>
>
> This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited.
>
> Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.
>
> ______________________________________________________________________________________
>
> www.accenture.com
>