Agganciando il protocollo HTTP / HTTPS in IE fa sì che le richieste GET ad essere sequenziale

Question

Sto utilizzando il PassthruAPP metodo per gancio nel HTTP / HTTPS richieste fatte da IE.

Si sta lavorando bene per la maggior parte, però ho notato un problema. Solo un download filo è attiva alla volta, normalmente IE utilizza due fili scaricare. Vedo due IInternetProtocol oggetti sempre creato, ma IE utilizza solo una alla volta.

Questo sta accadendo con IE7, non ho ancora provato con altre versioni.

Il problema sembra essere che IE ricade il download di oggetti uno alla volta in cui IInternetSession::RegisterNameSpace viene chiamato per uno qualsiasi dei suoi gestori predefiniti. Il codice qui sotto cause HTTP download per essere sequenziale, anche se sto registrando un HTTPS handler. La registrazione per il 'file: //' provoca lo stesso problema

.

CComPtr<IInternetSession> spSession;
CoInternetGetSession(0, &spSession, 0);

MetaFactory::CreateInstance(CLSID_HttpSProtocol, &m_spCFHTTPS);
spSession->RegisterNameSpace(m_spCFHTTPS, CLSID_NULL, L"https", 0, 0, 0)

Questo accade sempre per i primi elementi della pagina, ma sembra che dopo il completo documento è rilasciato, download simultanei possono verificarsi di nuovo. Ad esempio di codice JavaScript che viene eseguito dopo la pagina ha finito di caricamento può caricare immagini contemporaneamente bene.

Answer 1

E 'possibile aggirare questo problema applicando le patch del COM VTable per InternetProtocolRootEx::StartEx() sul registrati HTTP / HTTPS. Dal momento che questo non sostituisce direttamente il gestore di protocollo, IE non sarà fallback al modello singolo thread.

La tecnica è descritta qui:

http: // web .archive.org / web / 20130313164317 / http: //www.blackfishsoftware.com/blog/don/passthroughapp_bho_toolbar_intercepting_requests_responses

Answer 2

Sì, questo è noto, in base alla progettazione, e documentata in vari luoghi. (E 'fatto, perché non possiamo fare ipotesi circa la sicurezza filo di gestori di protocollo)

Questa è una delle ragioni per tanti che è suggerito che non si tenta di avvolgere il HTTP / HTTPS.