Hooking the http/https protocol in IE causes GET requests to be sequential

Question

I'm using the PassthruAPP method to hook into HTTP/HTTPS requests made by IE.

It's working well for the most part, however I noticed a problem. Only one download thread is active at a time, normally IE uses two download threads. I can see two IInternetProtocol objects getting created, but IE uses only one at a time.

This is happening with IE7, I haven't tried with other versions yet.

The problem seems to be that IE falls back to downloading items one at a time when IInternetSession::RegisterNameSpace is called for any of its default handlers. The code below causes HTTP downloads to be sequential even though I am registering a HTTPS handler. Registering for 'file://' causes the same problem.

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

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

This always happens for the first few items on the page, but it seems that after the document complete is issued, concurrent downloads can occur again. For example Javascript code that is executed after the page has finished loading can load images concurrently just fine.

Answer 1

It's possible to get around this problem by patching the COM VTable for InternetProtocolRootEx::StartEx() on the registered HTTP/HTTPS protocols. Since this does not replace the protocol handler directly, IE won't fallback to the single thread model.

The technique is described here:

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

Answer 2

Yes, this is known, by design, and documented in various places. (It's done because we cannot make assumptions about the thread safety of protocol handlers)

This is one of MANY reasons that it's suggested that you do not attempt to wrap the HTTP/HTTPS protocols.