Use resource tracking to see the img resource requested and subsequently 404'd. This occurs even though a selector was provided and the content was filtered so that the img was never explicitly added into the page.

Using a browser console and entering in the following in page with jQuery included you will see the img requested and 404'd even though it was never explicitly added to any elements in the page.

While Tim worked on this discovery, I can definitely confirm the behaviour. It might be edge case - its even difficult to create a fiddle for it. But for clarity sake...

Assume I have an HTML file and it has a div in the body. Additionally, I have a script tag that does this:

$('div').load('file.html h1');

And in file.html...

<h1>BOOM!</h1><img src="404.jpg">

The result of the load() call will look like this...

<div><h1>BOOM!</h1></div>

So far so good... But I check the JS Console, I will see a 404 error has been logged for that image tag that has a src set to an image file that does not exist. But I did not ask for this image, I only asked for the H1.

While it makes sense that jQuery will turn the entire response into a dom fragment that it can then filter the contents of - this could have very serious and unexpected behaviour.

Both IE and Firefox fetch the image immediately, and if they're appended to a document that had a base tag they don't re-fetch based on the new url (I used Fiddler on Windows to see the actual requests):

I'm not sure if this is really something that we can tackle on a fundamental level - at best it would require moving away from Document Fragments - but even then it's not clear if that would actually help (the same result would likely still happen with just innerHTML stuff). I'm going to close this as 'patchwelcome' to see if anything pops up in particular.