5

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.

watsonmw
  • 321
  • 2
  • 13
  • Incidentally, this problem is worse in IE8+, where the default connection limit is higher. – EricLaw Apr 08 '10 at 02:24
  • Just tested it, I get two download threads active at any one time with IE8, instead of the default 6 when no custom protocol handler is defined. – watsonmw Apr 08 '10 at 18:46
  • @EricLaw Has this been "fixed" in IE9,10 and ofcourse 11? Or do we have to hook the COM VTable.. –  Sep 28 '13 at 22:23
  • As far as I know, no, this hasn't been changed. This is a legacy extensibility point and it is not really even maintained any longer. – EricLaw Sep 30 '13 at 11:49
  • @watsonmw Can you post some code how you did it? That link doesn't provide much info. – user3060326 Apr 24 '14 at 13:18

2 Answers2

3

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

EricLaw
  • 56,563
  • 7
  • 151
  • 196
watsonmw
  • 321
  • 2
  • 13
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.

EricLaw
  • 56,563
  • 7
  • 151
  • 196
  • The following link mentions adding a custom protocol handler for HTTP/HTTPS incurs a performance penalty when browsing: http://msdn.microsoft.com/en-us/library/aa767759(VS.85).aspx Are there other performance penalties beside the single active download thread? – watsonmw Apr 08 '10 at 18:45
  • Links to the places where this is documented would be helpful to other people coming to this question. – watsonmw Apr 08 '10 at 18:52
  • So how one should intercept requests from IE if not wrapping HTTP(S) protocols? There are no documented techniques for this kind of task. – ReVolly Jul 01 '12 at 17:43
  • 1
    @Virtuality: Generally speaking, MSFT doesn't want you to wrap protocols. You could use something like FiddlerCore, but even it is really designed for specialized scenarios. – EricLaw Sep 30 '13 at 11:50