im using signalr-rc2 and use it for cross-domain long-polling calls on IIS7(not express)
everything works fine execpt OnDisconnected on server-side
when i hit the close button on browser(firefox or chrome) OnDisconnected invoked but
when i refresh the browser tab,,OnDisconnected does not invoked
however i test it on a small project an it works fine totally
my question is whats the diffrence between reloading browser page and closing it
i wait almost 15 minutes for delay of IIS to realize client disconnection but nothing happens
I found the problem it was two html tag in document
caused by asp.net mvc view render(i forgot to return partialview instead of view in action method)
Related
If I leave my current page on a asp.net Web application I want that all sessions get destroyed. For that I am using Session.Abandon() on Page_Unload Event. But if I do a Postback with a normal Button_Click I don't want to fire this event.
It would be awesome if you could help me.
Lingo
First you need to understand how the web works. When you access stackoverflow.com for example your are actualy seeing the past. The page you accessed it's already destroyed on the web server.
Based on that principle when you use Page_Unload or Session.Abandon if you actually close your browser you don't send any request for the web server so the web server didn't know (and don't care even) if you close your page.
For doing like
The page unload description act like this it's after being rendered it's had nothing with the close of the page.
"The Unload event is raised after the page has been fully rendered, sent to the client, and is ready to be discarded.
At this point, page properties such as Response and Request are unloaded and cleanup is performed.'
Reference (https://msdn.microsoft.com/en-us/library/ms178472.aspx)
You need to use javascript for doing this behaviour or try the new websocket that will keep the connection alive and the server could check if the client has lost the link with the server.
What is AsyncPostBack, SyncPostBack and what is the difference between those methods?
An asynchronous postback is accomplished using javascript to send an XMLHttpRequest, known as AJAX, without leaving the web page you are on. A synchronous postback is a normal form post request from the web page, resulting in a complete request cycle and a (re)display of the same or a different web page. The difference is that with an asynchronous request the web page stays the same and the user can continue to interact with it while the request is taking place. This can make the interface seem more responsive to the user and improve the experience. In a synchronous, or full, postback the web browser must wait while the request is sent back and the new page is loaded. You also lose, if you don't maintain it on the server and reset it on the new page, any state on the original web page.
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.
I have a long-running database query that I've placed in an asynchronous AJAX callback (or so I think) to allow the user to navigate to another page if they're not interested in the results.
Whether I call the query automatically after page load or on click, the page always locks up until it returns, i.e links and buttons don't work. Internet Explorer 6's own menus are fine however, so it's not that IE itself is overworked.
What could I be doing wrong? It seems as though my request isn't really asynchronous. Here is a code snippet:
this.XmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
this.XmlHttp.open("POST", url, true);
this.XmlHttp.send(data);
It's not the browser that blocks the page, it's the server.
IIS only handles one request at a time from each user. As the user already has a request from the AJAX call that the server is working on, the new request will be queued until the first request is handled.
To keep the long running request from blocking the user on the server you have to make the page that the AJAX call gets session-less. That way it's not associated to the user.
I have a JavaScript function that is manually calling a postback: __doPostBack('ctl00$searchButton', '');
The above searchButton is on a Master page and has an onclick event wired up. At the end of the event, I am re-directing to another page. This re-direct fails when the postback is called from JS. It works properly when the onclick is fired normally. I'm moving away from the auto fire in order to perform some client-side operations that are drastically reducing the HTML mark-up. I have tried replacing the Response.Redirect with a Server.Transfer with no success.
Any ideas here?
I suggest starting a debugging session and setting a breakpoint on that pages Load() method and seeing what the execution path is.
Also, try an HTTP proxy (HttpFox for FireFox plugin, Charles Proxy for an OS level proxy) to see what exactly the redirects are doing.