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.
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.
Page Load, as a sentence of 2 words, means when the page is loaded, means, when all elements are loaded.
Let's say I have a page called Ask.aspx, and this page is only allowed to users who have signed in, so technically I would write something like this :
if(Session["id"]==null)
Response.Redirect("Login.aspx");
This mean, that I'm testing the Session AFTER the page loads, theoretically, I think it sounds wrong, now of course I won't notice it, it will be fast, I will try to access the page, then I'm redirected to Login.aspx, but... is it correct to test the Session on Page Load method?
The Page_Load is part of the page lifecycle. It is called when the Server loads the page, not when the Client loads the page...
So this is the correct place to check the Session Variable...
You're actually saying: Before I post the page back to the client, check if I have the ID property set for this session... If I don't - tell the client to redirect to the Login.aspx page...
This is the correct way of doing this...
I recommened you also read about Server.Transfer. The difference between it and Response.Redirect is that in Server.Transfer the server itself "redirects" to another page and outputs the result of the new page back to the client (without the client knowing about it).
If you are trying to limit access to specific pages, you would be better off using forms authentication.
http://support.microsoft.com/kb/301240
It is fairly easy to setup and it allows checking of credentials before the request is passed to the asp.net pipeline. In what you are doing, your page goes through the entire lifecycle (controls are rendred and bound to data, access to database, calls to web services etc.) before the request is rejected. Depending on your situation, this might be costly and will not scale well.
Edit: You can also hook in to the AcquireRequestState event in the global.asax. This will also spare the entire page life cycle.
I'm calling a static Page method via javascript that takes between 5s and 10 min. I'd like to give my user the choice to either continue waiting for the request to complete or not, and use window.setTimeout() to check back every 30s.
I've tried both location.href = '/newpage.aspx' or firing a button's click handler (which does similar redirect) to redirect the user prior to completion of the page method, to no avail. I can immediately send user to a simple html page, but a redirect to any aspx page involving server-side appears to block. When the page method finally completes, the redirect does succeed.
Is this:
a browser issue? If all modern
browsers support at least 2
concurrent requests per domain, why
wouldn't this work?
a framework
limitation?
a desirable design
pattern or even possible? I've
checked, and after redirecting to an
HTML page, the original request continues processing (db updates, no problem).
Are Page method calls simply not asynchronous from a "concurrent HTTP request" perspective?
Any insight greatly appreciated!
It sounds like you're blocking on InProc Session, which is limited to one concurrent request per unique session. If you don't need access to the Session in your page method, you can disable it by modifying the WebMethod attribute:
[System.Web.Services.WebMethod(EnableSession=false)]
Is there a way to detect page refresh without using viewstate in asp.net webforms ? I was wondering if it was at all even possible since asp.net mvc doesn't use viewstate for example.
I am trying to avoid using viewstate alltogether to keep my page size small.
IsPostBack is not going to work because its a F5 or Pager refresh case not the post back from any event.
You can detect a page refresh on the server-side using IsPostBack. In fact, any code you put in Page_Load in your code-behind will run each time the page is refreshed. Or have I misunderstood your question?
Why can't you just use IsPostback in the code behind with ViewState disabled in the page? This way you can do whatever you need to in the code behind and not worry about ViewState clogging up your page size.
You can disable ViewState in the page by adding the enableViewState flag to the #Page directive.
The only other thing I can think of is to have a piece of javascript code which catches the key press of F5, but obviously this will only capture an F5 refresh and not a Refresh-button refresh.
This site shows how to capture key presses with Javascript:
http://www.go4expert.com/forums/showthread.php?t=2733
The http protocal is stateless and after a response is send to the one how requestet it removes all trace of him except his session. The way webforms work is that it serialize your page state and send it to the client and then back to the server when you make a postback(A form post request). So you can save information about your client in his session about the page he been on before and then check in the session if he request the same page again.
I'm making a request for a page (lets call it page A). However, the request gets redirected to another page (page B). As soon as the request handling starts, URL property of Request object on the server points to page B (however, RawURL still points to page A).
I am not able to find any piece of code in the applications that explicitly redirects anything to page B. I guess it happens during some request preprocessing by asp.net, but I don't know what's actually happening behind the scene.
So I need an advice on how to continue debugging this issue :)
Thanks!
This sounds like a Server.Transfer, might want to search the code base for that.
http://msdn.microsoft.com/en-us/library/ms525800.aspx
http://www.developer.com/net/asp/article.php/3299641
I would put a breakpoint on the page that calls the problem page and see at which point control is passed over to Page B.
Also, you can easily see if the redirection is using Response.Redirect or Server.Transfer by viewing the http headers sent. A Response.Redirect sends a 302 redirect header to the client, while Server.Transfer doesn't.