Einhaken des http / https-Protokoll im Internet Explorer verursacht GET-Anfragen sequentiell sein

Question

Ich bin mit dem PassthruAPP Verfahren zum Haken in HTTP / HTTPS-Anfragen von IE.

Es funktioniert gut für den größten Teil, jedoch bemerkte ich ein Problem. Nur ein Download-Thread aktiv ist zu einer Zeit, in der Regel IE verwendet zwei Download-Threads. Ich sehe zwei IInternetProtocol Objekte erstellt bekommen, aber IE verwendet nur einen nach dem anderen.

Dies geschieht mit IE7, ich habe noch mit anderen Versionen nicht versucht.

Das Problem scheint zu sein, dass der IE fällt zurück Artikel einer nach dem anderen auf das Herunterladen, wenn IInternetSession::RegisterNameSpace für eine ihrer Standard-Handler aufgerufen wird. Der folgende Code Ursachen HTTP Downloads sequenzielle sein, obwohl ich einen HTTPS bin Registrierung Handler. Die Anmeldung für 'file: //' das gleiche Problem verursacht

.

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

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

Dies geschieht immer in den ersten paar Elemente auf der Seite, aber es scheint, dass, nachdem das Dokument vollständig ausgegeben wird, simultane Downloads wieder auftreten können. Zum Beispiel Javascript-Code, der nach der Seite ausgeführt wird, beendet Laden kann nur feine Bilder gleichzeitig laden.

Answer 1

Es ist möglich, dieses Problem zu umgehen, indem die COM VTable für InternetProtocolRootEx::StartEx() Patchen auf der registrierten HTTP / HTTPS-Protokolle. Da dies nicht den Protokollhandler direkt ersetzt, IE wird nicht Rückfall auf das einzelne Thread-Modell.

Die Technik ist hier beschrieben:

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

Answer 2

Ja, das ist bekannt, durch Design und in verschiedenen Orten dokumentiert. (Es ist geschafft, weil wir nicht Annahmen über die Thread-Sicherheit von Protokollhandler machen kann)

Dies ist einer der vielen Gründe, dass es empfohlen, dass Sie nicht versuchen, die HTTP / HTTPS-Protokolle zu wickeln.