Creazione di una connessione HTTP robusta per gli utenti fittizi con WinINET

Question

Sto creando un programma che scarica un semplice file da Internet su Windows, utilizzando l'API della famiglia Wininet perché voglio utilizzare il suo comportamento proxy compatibile con IE. Come tutti sapete, IE corrente ha diverse impostazioni proxy: auto-detect (WPAD), autoconfigurazione (PAC), manualmente singolo URL, server proxy per protocollo, calze, diretto, ... Per la maggior parte degli utenti, il "download diretto" " funziona bene; tuttavia per alcuni utenti (in particolare quelli dietro firewall/NAT), hanno sempre bisogno di speciali impostazioni proxy quando effettuano le connessioni.

È doloroso scrivere codice per gestire tutti questi casi, quindi spero che WinINET con InternetOpen (INTERNET_OPEN_TYPE_PRECONFIG) possa aiutarmi. Lo fa per la maggior parte degli utenti, tuttavia trovo ancora alcuni utenti che si lamentano di un errore di connessione. Questi utenti possono avere ambienti di rete molto speciali (ad es. Necessitano di nome utente/password per il proxy) e la connessione diretta non funziona per loro.

A volte gli utenti fittizi avevano una configurazione errata e mi piacerebbe che wininet provasse "tutte" le possibili impostazioni proxy per me; sfortunatamente il INTERNET_OPEN_TYPE_PRECONFIG proverà solo quello configurato dall'utente, non "tutte le possibili impostazioni del proxy".

Quindi la mia domanda è: come posso creare un programma con la più forte capacità di risolvere tutte le connessioni http (specialmente per la configurazione del proxy) per gli utenti fittizi (cioè, non capiscono come configurare il loro sistema)? Esiste un modo suggerito per effettuare connessioni HTTP senza la necessità di occuparsi del proxy? (cioè, un risolutore di connessione "super" che proverà tutte le possibili impostazioni proxy), o se c'è qualche metodo per dire a WinINET di abilitare tutte le sue impostazioni proxy per creare una connessione?

Answer 1

Un algoritmo ragionevole sarebbe questo:

1. provare una connessione utilizzando le impostazioni proxy correnti dell'utente (quelli che IE utilizza). Questi sono quelli che più probabilmente lavorano. Vedere WinHttpGetIEProxyConfigForCurrentUser() su MSDN per ottenere queste impostazioni o INTERNET_OPEN_TYPE_PRECONFIG in WinINet.

2. se ciò non riesce, provare una connessione diretta.

3. se ciò non riesce, provare un rilevamento automatico WPAD utilizzando WinHttpGetProxyForUrl. (WPAD è il modo automatico in cui i client possono trovare un file Proxy Auto-Config (PAC) su una rete, in genere una rete aziendale.) Si desidera selezionare l'opzione per controllare sia DHCP che DNS per il file proxy. WinHTTP AutoProxy Functions su MSDN contiene un esempio di codice che utilizza questa API e molte informazioni di supporto. Se questo succede, recupererai le informazioni proxy che puoi quindi collegare al tuo codice di download HTTP. AFAIK, non esiste un'opzione WinINet equivalente per eseguire automaticamente un nuovo rilevamento WPAD: solo WinHTTP.

4. Successivamente è possibile provare a cercare le impostazioni del proxy di Firefox. This SO answer dettagli informazioni sulla posizione e il formato di queste impostazioni in modo da poter accedere a loro a livello di programmazione.

5. se ciò non riesce, chiedere all'utente (nell'interfaccia utente) di verificare che la propria connessione Internet sia effettivamente connessa. in realtà è molto più comune per gli utenti essere disconnessi rispetto a tutti i passaggi di rilevamento del proxy di cui sopra per fallire. chiedere all'utente di aprire il proprio browser per assicurarsi che possa accedere a un sito Internet; se i passaggi precedenti non riescono, il loro browser non è in grado di vedere il Web. Una volta che l'utente afferma di essere connesso, ripeti i passaggi 1-3.

6. se tutto ciò non riesce, si ha davvero poca scelta ma chiedere all'utente di specificare manualmente le proprie informazioni proxy.Probabilmente vorrai clonare l'interfaccia utente proxy di IE o Firefox e trasformare le impostazioni dell'interfaccia utente nei parametri appropriati per configurare le opzioni proxy quando scarichi quel file.

Nota che non c'è alcuna magia per delega detection-- le scelte sono utilizzare le impostazioni dell'utente, utilizzare le impostazioni del computer di default, utilizzare una connessione diretta, utilizzare WPAD per trovare un file PAC, o chiedere all'utente. Sfortunatamente non c'è modo di "creare connessioni HTTP senza la necessità di occuparsi di proxy".

BTW, anche se è possibile utilizzare WinHTTP solo per il rilevamento del proxy e quindi utilizzare WinINet per il recupero del file, suggerirei di utilizzare WinHTTP per entrambe le parti. Quando si desidera la massima flessibilità e controllo sull'interazione HTTP (oltre a una migliore stabilità rispetto a WinINet), è preferibile WinHTTP.

UPDATE 2:

J.J. ho avuto una buona idea sopra-- Ho aggiunto un passaggio per controllare le impostazioni del proxy di Firefox. Poiché i proxy oddball si trovano generalmente negli ambienti aziendali (che tendono a standardizzarsi su IE) è meno probabile che ciò possa essere d'aiuto, ma vale la pena provarlo.

UPDATE: Ho appena curato la sezione precedente in risposta alla corretta commento di Francesco: WinHTTP non è il "successore" per WinINet in senso stretto (cioè il 100% delle caratteristiche di WinINet sono avilable in WinHTTP). Piuttosto, WinHTTP è progettato per applicazioni che utilizzano HTTP per lo scambio di dati e non si preoccupano dell'integrazione con cache, cookie, interfaccia utente remota di Interet Explorer, ecc.

Le applicazioni server rientrano sicuramente in questa categoria (WinHTTP, a differenza di WinINet, è sicuro per l'utilizzo nelle app del server), ma anche molti software client lo utilizzano, ad esempio il client Windows Update su ogni PC moderno. In generale, WinHTTP è preferibile per un'app client che deve scaricare file su HTTP e ha bisogno di un controllo più dettagliato sulla rete e vuole controllare la propria interfaccia utente.

WinHTTP è più pratico (ad esempio, è necessario effettuare una chiamata API per ottenere le informazioni sul proxy e un'altra per utilizzare le informazioni sul proxy) ma quel livello extra di controllo consente di fare cose che non si possono fare con WinINet, come forzare ignorando le impostazioni del proxy dell'utente e provare un nuovo rilevamento WPAD.

Answer 2

La descrizione migliore che ho trovato del processo utilizzato da IE è in How the Windows Update client determines which proxy server to use to connect to the Windows Update Web site. Combina la sequenza quando utilizzi IE per accedere a Windows Update con le tue conoscenze di WinINet o WinHTTP WinHttpGetIEProxyConfigForCurrentUser, WinHttpDetectAutoProxyConfigUrl, WinHttpGetProxyForUrl e WinHttpGetDefaultProxyConfiguration per connettere l'applicazione.

Ecco la sequenza dall'articolo KB:

1. Se l'utente è configurato per rilevare automaticamente le impostazioni, cercare un file PAC tramite WPAD.
2. Nessun file PAC trovato? Se l'utente ha impostato lo script di configurazione automatica IE, utilizzare tale file PAC.
3. Ancora nessun file PAC trovato? Cerca un proxy. Se l'utente ha configurato manualmente le impostazioni del proxy IE, usale.
4. Nessun proxy IE configurato? Controlla la configurazione proxy predefinita.
5. Nessun proxy predefinito configurato? Utilizzare una connessione diretta.