a) In Asp.Net we can check whether a request is a postback or not via Page.IsPostBack property.But where does this property get its value from? Thus, where in the incoming request does browser put this value?
b) As far as I can tell, hitting a reload button also causes browser to send form data back to the server. Thus, is under the hood hitting browser’s reload button same as pressing a submit button ( which is nested within a FORM element)?
c) Assuming browser displays A.aspx for the fist time and assuming user clicks browser’s reload button, then I would think this request will be considered as a postback by Asp.Net (especially since browser also sends back any form data), but it’s not. Why?
thanx
The IsPostBack property only looks to see if the request made is a POST request action. If it is a POST, then IsPostBack returns true.
Hitting reload / refresh on a browser does NOT in general send any form data to the server - most of the time this causes a GET request (which is the default request you send any time you first visit a site).
If you click refresh on a page that was received as a result of a POST operation, then the browser will ask the user if they would like to submit the data again before doing the POST request again. A browser will not resubmit any form data unless the user confirms it (at least that is how it works in the IE, Firefox and Chrome).
Fiddler is a great tool to help with this kind of situation. It sits in the middle between the browser and the server and you can watch all of the traffic go back and forth. You can download it here.
Related
In ASP.NET web application what is the difference between F5 and ENTER button
press on browser, And also please differentiate across the browsers.
If you hit enter browser sends a GET request.
If you hit F5 browser sends the last request again. So if last one was a post request (sent form data) it'll ask before sending.
f5 button will send the prior submitted request to the browser. e.g if you hit submit button which saves data in database and if you press f5 the submit button will get executed. Hitting enter will request to webserver for the page you requested. this will create new request to the server. In F5 ISPOSTBACK property will be true even if page is refresh. On hitting enter postback property will be false and again whole page gets loaded
If you hit Enter on the URL it would load from the cache of browser not show changes load previous state
if u press F5 it will run the last state of Website (Example if you submit any action on the page it would perform from start to submit function.
My recommendation is that you use Ctrl+R in any browser for perfect result after enter activity
Thanks,
Please mark it answer if its helps you
Some small percentage of the time, we see a flow like this, deducing from looking at server logs (I have not been able to reproduce this case with any browser):
At time A, client hits our page:
with no cookies
gets back a response with a Set-Cookie HTTP response header that gives them a session id of B
body has JS to fire an AJAX request /ajax/foo.
At time A + 1 second, client hits us with the AJAX request to /ajax/foo
the referrer is set to the page in step 1 that fired the AJAX, as expected
with no cookies - why?
gets back a response with a Set-Cookie header that gives them a session id of C (expected, since they didn't send us a cookie)
At some time slightly later, all of the client requests are sending either session id B or C - so the problem is not that the browser has cookies turned off.
This seems to be essentially a race condition -- the main page request and the AJAX request come in together very close in time, both with no cookies, and there is a race to set the cookie. One wins and one loses.
What is puzzling to me is how could this happen? My assumption is that by time the browser has read enough of the response to know that it needs to fire an AJAX request, it has already received the HTTP response headers and thus the Set-Cookie response header. So it seems to me that the client would always send back the cookie that we set in the page that fired the AJAX request. I just don't see how this could happen unless the browser is not promptly processing the Set-Cookie response.
Like I said, I can't reproduce this in Firefox, Safari, or Chrome, but we do see it several times a day.
There is a new feature in google chrome that could cause this misbehavior. It is called prerender.
Prerendering is an experimental feature in Chrome (versions 13 and up)
that can take hints from a site’s author to speed up the browsing
experience of users. A site author includes an element in HTML that
instructs Chrome to fetch and render an additional page in advance of
the user actually clicking on it.
Even if you do not proactively trigger prerendering yourself, it is
still possible that another site will instruct Chrome to prerender
your site. If your page is being prerendered, it may or may not ever
be shown to the user (depending on if the user clicks the link). In
the vast majority of cases, you shouldn’t have to do anything special
to handle your page being prerendered—it should just work.
For more information read: http://code.google.com/chrome/whitepapers/prerender.html
Edit:
You could trigger prerender on your page with: http://prerender-test.appspot.com/
a) Does the cookie have an expiration time?
b) If so, have you tried to reproduce it by setting the computer's clock back or forward by more than the TTL of the cookie? (I mean the clock of the computer running the browser, obviously; not the server running the app ... which should be a separate computer whose clock is set accurately.)
I've seen this as well; it seems to be triggered by users with screwed up system clocks. The cookie was sent with an expiration date that, from the browser's perspective, was already past.
What is the difference between the following:
Server.transfer?
Response.Redirect?
Postbackurl?
When should I decide to use which?
Server.Transfer tells ASP.NET to redirect processing to another page within the same application. This happens completely server side. This is more "efficient" as it happens on the server side but there are some limitations with this method. The link below describes some of these.
Response.Redirect actually sends a HTTP 302 status code back to client in the response with a different location. The client is then responsible for following the new location. There is another round trip happening here.
PostBackUrl is not a "transfer method" but rather an property that tells the browser which URL to post the form to. By default the form will post back to itself on the server.
Here's a good link: http://haacked.com/archive/2004/10/06/responseredirectverseservertransfer.aspx
Server.Transer() works server-side. It will reply to the client with a different page than the client requested. If the client refreshes (F5), he will refresh the original page.
Response.Redirect() replies to the client that it should go to a different page. This requires an additional roundtrip, but the client will know about the redirect, so F5 will request the destination page.
PostbackUrl is a property telling an ASP control where to go when clicked on the client. This does not require an additional round trip while keeping the client informed. If you can use this method, it's generally preferable to the other choices.
Server.Transfer:
Transfers request from one page to other on server.
e.g. Browser request for /page1.aspx
Request comes on page1 where you do Server.Transfer("/page2.aspx") so request transfers to page2 And page2 returns in response but browser's address bar remains showing URL of /page1.aspx
Response.Redirect
This statements tells browser to request for next page. In this case browser's address bar also changes and shows new page URL
PostBackUrl
You can mention it on Buttons or Link buttons. This will submit the form to the page provided. It is similar to the:
<form method="post" action="/page2.aspx">
is there a way from a asp.net-page code behind with "Request.Redirect()" or another method to redirect to the last page (like Javascript history back)?
You can check the Request.UrlReferrer property, which will be set if the user has navigated to the given page from another one. This is nothing more than the HTTP Referrer header that a browser will set. This will be null if the user navigates to your page directly.
HTTP is stateless, so theres no way of being able to read the browsers history (on the server) in the same way that Javascript can (its client side).
However there are a couple of tricks you can use:
Javascript could write the URL into a textbox which gets submitted to the server
The last URL visited could be stored in session - which can be retreived on a later visit
If using the URL in session method, you'll probably want to code this into a HTTP handler (not module) and this will fire automatically on every request.
Obviously these will only work if the user has previously visited a page, and not directly.
What whould be the best way to prevent multiple users on a page?
For example if a user is at the page "Home.aspx", no other users should be allowed to go there.
I'm using asp.net on the server and the js-frameword jQuery on the client side.
The easy part is only allowing one user to access a page. You can for example store a session id in an application variable to keep track of who's on the page.
The hard part is to know when the user leaves the page. The HTTP protocol only handles requests, so the server only knows when a user enters the page. There is no concept of "being on" a page in the protocol.
You can use the onunload event in client code to catch when a user goes somewhere else, however this will not always work. If the user loses the internet connection, there is no way to communicate back to the server that the user leaves the page. If the browser or computer crashes, there will naturally be no onunload event.
You can keep requesting data from the server, by for example reloading an image on the page. That way the server can know if the user is still on the page at certain intervals. However, if the user loses the internet connection, the server will think that the user has left, while the user thinks that he/she is still on the page.
Another problem is browser history and cache. A user might leave the page, then go back to the page again. You have to make sure that the page is not cached, or the browser will just use the cached page and the server has no idea that the user thinks that he/she is on the page again.
Agreed with Guffa, you cannot be sure that the browser is already on the page or not, you can only check if the browser is already connected to that page or not.
You can do a sort of "ping", but its more a trick than a 100% working solution and it requires javascript enabled.
I didn't do it but I should look at XMLHTTPRequest and onreadystatechange to handle this :
1) On page load, the browser (client) initiate a XMLHTTPRequest with the web site (server) then wait for callback with the onreadystatechange event.
2) The web site receive the request and "mark" the page as "in use" with the current DateTime.Now.
3) Then the web site sends the response.
4) The onreadystatechange event get the response and the event code re-request the server to re-initiate the 2 after 1 min.
5) If another client request the page, the server check the DateTime mark : if the mark is greater than 1min ago, it means the client didnt respond to the request and may not be on the page again.
Not sure why you would want to do this because it flies in the face of web usability. You could do a locking mechanism on each page in server side code (write user name, page and time to a DB), which is freed up when they go to another page. You would then check on a the page load event to find out if anyone currently has that page locked. However, and this is a big however - have you considered what happens if somebody just shuts their browser down or walks off and leaves it on a page. You would need to seriously consider a timeout to free up locks too. That would need to be a back ground service, either in global.asax as global code or a separate process.
Maybe use static variables to hold the ip of the first user to access the page and then check whether other requests come from the same ip, otherwise display a "no access" page.
make sure you use lock it:
Object thisLock = new Object();
lock (thisLock)
{
// access static variables
}
You should also use "Session_End" method in global.asax to remove the ip address in case the user leaves your website without pressing the logout button