Browser fires request twice to image handler - asp.net

I am working on a web application. Some images are calling a web provider, which renders the picture, and send it to the client (the html looks like img ... src="/WebProviders/ImageHandler.ashx?.../>).
The problem I have encountered is that both IE8 and Firefox 3.6.8 fire the request to the handler more than once, yet not consistently. I could not trace a pattern (the same image sometimes cause one and sometimes several requests).

Have you used a product like Fiddler to view the HTTP traffic from the web page to the server, that will allow you to see if that is firing two requests to the handler.

Related

Chrome dev tools replacing AJAX request with redirect

I've got an app that makes an AJAX call using jQuery. Upon error, in Application_Error, there's a Response.Redirect which sends you to an error page (it's designed for regular page errors, but it fires on failed AJAX requests as well).
In my real project, when I make this AJAX request, the Network tab of the Chrome dev tools shows the original request and URL for a split second, and when the error occurs, that line goes away and gets replaced by the request to GenericError.aspx. In reality, the original call received a 302, and there was a second call to GenericError.aspx - this is confirmed with Fiddler.
I tried to recreate with new small projects, and those always show properly, with both the 302 and the error page showing up as separate lines.
The "Preserve Log" checkbox is checked, but they both behave the same if unchecked as well.
The AJAX requests and 302 responses are practically identical between my real project and the small one, so I don't see why Chrome would treat them differently.
Are there any config options or anything I might be missing that could change the way Chrome dev tools would treat AJAX responses with 302 redirects?

Sys.WebForms.PageRequestManagerParserErrorException with IE

I am working on a relatively complex asp.net web forms application, which loads user controls dynamically within update panels. I've run into a very peculiar problem with Internet Explorer where after leaving the page idle for exactly one minute you receive a Sys.WebForms.PageRequestManagerParserErrorException javascript exception when the next request is made. This doesn't happen in Firefox and Chrome. When the server receives the bad request, the body is actually empty but the headers are still there. The response that is sent back is a fresh response you would get from a GET request, which is not what the update panel script is expecting. Any requests done within a minute are okay. Also any requests made following the bad request are okay as well.
I do not have any response writes or redirects being executed. I've also tried setting ValidateRequest and EnableEventValidation in the page directive. I've looked into various timeout properties.
The problem resided with how IE handles NTLM authentication protocol. An optimization in IE that is not present in Chrome and Firefox strips the request body, which therefore creates an unexpected response for my update panels. To solve this issue you must either allow anonymous requests in IIS when using NTLM or ensure Kerberos is used instead. The KB article explains the issue and how to deal with it.KB251404

browser requesting for images after text

Does a browser request for images after it finishes with the basic text and background. If yes, does this request behave like a separate HTTP request like ones coming up by clicking a link etc?
Does a browser request for images after it finishes with the basic text and background.
No. The requests for images are started immediately when the browser sees an <img> tag, the browser doesn't wait until the page finishes loading. You can easily see it with the Firebug network monitoring for example.
does this request behave like a separate HTTP request
Yes, an image request is a usual HTTP request. However, most of the time an existing connection is reused for that (see persistent HTTP connections).

HTTP request/response handling untill page life cycle commences

What happens from the point an HTTP request is received on a TCP/IP port up until the Page fires the On_Load event?
The below link should give you detailed explanation about the asp.net application life cycle process.
http://msdn.microsoft.com/en-us/library/ms178473.aspx
Brifely to say.
Request is received by the server, the server determines the ISAPI extension to handle the request based on filename extension.
In case this is first request, it will create an app domain for maintaining isolation with this and other applications running.
then it creates hosting environment which will also create the objects like HttpContext, HttpRequest and HttpResponse.
After this the HTTPApplication object is created .
Afterwards the events in the global.asax which is the class inherited from the HTTPApplication object fires in the order defined in the link above.
The browser recieves the http response
The browser parses http headers and starts reading the HTTP content.
Parsing first the <head> section and parsing this, putting external resources on the get queue (first, css then javascript, ideally)
Parsing the <body> content and drawing elements on the viewport.
When the DOM is drawed to screen and is completely rendered. the page fires the on_load event.
When the HTTP request reaches the server, the server will then prepare the necessary file that is requested by the client and send it to the client. The client will then receive the entire content of the HTML page. Note that this is just the HTML and the browser still needs to make additional requests to the server for images and other types of files like applets if necessary.
Finally, to answer your question, it'll have to depend on where you put the onload event. If it's for the then this will be invoked when the body has completed loading. If it's in other node items, as we call it in JavaScript, then it'll be on the complete loading of that particular item.
Hope it helps :)
Cheers!

Is it correct to say that a web browser always knows when a web page is completely loaded?

A browser sends a GET request for a static web page to a server. The server sends back HTTP OK response with the HTML page in the HTTP body. Looking at the Content-Length field or looking for the terminating chunk or some other delimiter for some other encoding the browser can know if it has received the web page and subsequently all its embedded objects (images etc.). Is it correct to say that in this case the browser always knows when a web page has completely loaded and that it will see no further network traffic?
Now if the page is dynamic (lets say facebook or gmail), where you might receive notifications or parts of the page gets updated using AJAX or javascript running in the background, here also the browser should know when the page has loaded. What if the server is pushing some updates to the client. Is it possible in this scenario for the browser to know when it has received the full update?
So, is there any scenario in which a browser doesn't know when it has fully received the data (static or dynamic) it has requested from a web server or push-based updates the server is forwarding to it?
I can only imagine (for the static case) the one scenario when Content-Length is not set. It's not mandatory to send it for the server.
Potentially, of course, in a page containing scripts, one could also have other scenarios where the script loads bits and pieces one by one with delays (including the AJAX scenario you mentioned). This way the browser would not know in advance either. In such a case it would know "for the moment" that the page has loaded completely, but the next action from the script would invalidate that assertion again.
You do not need AJAX to get in a situation where not all elements in the page are loaded even after the page itself has been loaded. A little javascript is all that you need (been a while since I last worked with JS, there might be some syntax errors)
<img id="dyn_image" src="/not_clicked.gif">
<input type="button" onclick="javascrit:document.get("dyn_image").src="/clicked.gif">
There are cases when the server uses some kind of push technology, for example Comets. In this case a request (generally Ajax request) is sent, without receiving any response (obvoiusly no HTTP headers as well), but leaving the TCP connection open. This may take long time, but still may be considered as a sub-case of Ajax calls.
The other case is HTML5's WebSocket technology. In a WebSocket the server side can push data to the client side without explicit request from the client side.
These two can be combined, so the answer to your question is: yes, there can be cases when you cannot predict that the network traffic is over or not. The common (in all cases) is that the client side must leave a channel open to the server.

Resources