Cruel Bug and the IIS Default Document

Last week, one guy from our QA department called me with a bug he found in one of our Web forms. After a short debugging I have discovered that one of the Session variables has been overwritten by with the wrong data – after been filled with the right data.
The code which causes the problem was not in the requested Web Form. Actually, it was on our "Default Document" - Default.aspx (which we declared in IIS).
But why is this default page been loaded? Who called it?And why does the browser gets the right page and not the default page if it does been called?
The next step was to put a breakpoint on the unwanted code, and watch for the "Call Stack" to see who called this code. This is a dead end. No user code calls this page.
But wait, maybe the application is being redirected to this page by "Response.Redirect" or by "Server.Transfer"?But the answer (after checking all the call to those two functions) is – No.
"Application_BeginRequest" in "Global.asax" is our next station.This is a good place to out a breakpoint, and it works this time too.
My breakpoint is being hit twice, once for the requested page, and again for the Default document page.
So, now I know that the unwanted code runs because the browser requested it.But when looking on the source of the page received by the user's browser, I can't find any redirection to the default page…
And then I got it.
One of the images tags in the html source was:

It was without any file name because there wasn't any image for this item in the DB, and the programmer hasn't checked for empty strings in this field.The browser requests this path from IIS, which in turn translate it to a request for the default document page. This, of course, explains why the browser doesn't show the default document. It asks for it as in image…I have just removed this image from the page to see if it solves the problem…
NO. It still happens.
I have read the html source again and again, searching for another mistake like that…YES!!! I got it!

The browser take the empty string of the "src" attribute as a request to the current path, which IIS answer with the default document again!
Conclusion:
Never leave any unspecified "src" attribute. You'll end with the browser requests the default document of the current directry.
p.s.
After I have finished to write this blog, I have found this blog.
I wish I have read it before meeting this bug...