I have a hidden iframe that refreshes every now and then, in order to keep the ASP.NET session up and running, for as long as the user is online.
However, I have been getting reports of users experiencing session timeouts, so now I am in doubt of what is needed to reset the session timer.
The hidden iframe's content page (simple html page) refreshes itself at a certain interval, which is significantly less than the session timeout.
My question is: Is it enough (for the session timer to reset) to let the page refresh itself, even when the server responds with a HTTP/1.x 304 Not Modified?
Is it simply the GET request itself that tells the webserver to reset the session timer?
Or do I need to make sure to actually fetch the page and receive a HTTP/1.x 200 OK response?
All you have to do to keep the session alive is send a request to a page from the current session. You can do this via iframes, or via ajax.
If you simply refresh the page in the IFrame, the response may be a cached one - thus the 304. You have to send a fresh request every time -
var url = "http://domain.com/defibrillator.aspx?" + (new Date()).getTime();
E.g.
http://domain.com/defibrillator.aspx?1556467987987
http://domain.com/defibrillator.aspx?5448796497878
http://domain.com/defibrillator.aspx?4123165487987
....
EDIT 1
Or you can use the Refresh HTTP header attribute.
EDIT 1.1
If you are using the codeproject article mentioned above, then try to model it using AJAX instead of iframes - it would save you a few bytes of extra iframe markup.
EDIT 2 - About HTTP 304 Not Modified
If the client has performed a
conditional GET request and access is
allowed, but the document has not been
modified, the server SHOULD respond
with this status code. The 304
response MUST NOT contain a
message-body, and thus is always
terminated by the first empty line
after the header fields.
This means that the request hasn't reached the ASP.NET pipeline, and has directly been served by IIS itself. ASP.NET environment doesn't know that a request has been made. So, it won't perform the session renewal.
Related
I'm building a simple CRUD application where there is a client, a server, and a database.
The client can send two types of requests to the server:
POST requests that update a row in the database.
GET requests that retrieve a row in the database.
One requirement of my application is that the requests have to be handled in the order in which they were sent from the client. For example, if the user makes a POST request to update row 1 in the database, then they make a GET request to retrieve row 1 in the database, the response to GET request must reflect the changes made by the previous POST request. One issue is that there is no guarantee that the server will receive the requests in the same order that the requests went sent. Therefore, in the example above, it is possible that the server might receive the GET request first, then the POST request later, which makes the response to the GET request not able to reflect the changes made by the previous POST request.
Another requirement of the application is that the client should not have to wait for the server's response before sending another request (this constraint is to allow for faster runtime). So in the example above, one possible solution is let the client wait for the server response to the POST request, and then it can send the GET request to retrieve the updated row. This solution is not desirable under this constraint.
My current solution is as follows:
Maintain a variable on the client that keeps track of the count of all the requests a user has sent so far. And then append this variable to the request body once the request is sent. So if the user makes a POST request first, the POST request's body will contain count=1, e.g. And then if they make a GET request, the GET request's body will contain count=2. This variable can be maintained using localStorage on the client, so it guarantees that the count variable accurately reflects the order in which the request was made.
On the server side, I create a new thread every time a new request is received. Let's say that this request has count=n. This thread is locked until the request that contains count=n-1 has been completed (by another thread). This ensures that the server also completes the requests in the order maintained by the count variable, which was the order in which the request was made in the client.
However, the problem with my current solution is that once the user clears their browsing data, localStorage will also be cleared. This results in the count getting reset to 0, which makes subsequent requests be placed in a weird order.
Is there any solution to this problem?
As per my understnding the difference between Response and Request is below
Request is - We request to server for like .aspx page
Response is - We get the .aspx page from server
So, I think, request is toward Server and response is what we got.
We have following terms
Request.QueryString
Request.RawUrl
Request.MapPath()
All these seems to go to server first and brings back the associated data. But the following term is contrary ?
Request.Cookies
Because the cookies creates at client side and value part is also fetched at client side using Response.Cookies
Your comments?
Query - 2 - Why it is useful to create/Access cookie using Request/Response.cookies? Because it can be created/fetched at client end in JavaScript.
Query 3 - Cookie resides at client end. Why do we send request to server ?
Query - 4 - Why do we write Response.Cookies? to go to server? Why? it creates at client end and accessed from client end. right? Why do we write Request.Cookies? Means fetching cookie information from server? Cookie is at client end. right?
"When a browser makes a request to the server, it sends the cookies for that server along with the request. In your ASP.NET applications, you can read the cookies using the HttpRequest object, which is available as the Request property of your Page class. The structure of the HttpRequest object is essentially the same as that of the HttpResponse object, so you can read cookies out of the HttpRequest object much the same way you wrote cookies into the HttpResponse object."
ASP.NET Cookies Overview
"Cookies are sent to the browser via the HttpResponse object that exposes a collection called Cookies. You can access the HttpResponse object as the Response property of your Page class"
Beginner's Guide to ASP.NET Cookies
Every time you send a Request to server, the cookies for that server are also sent.
Also, when the server sends you a Response it can include cookies for the next Request you send it to.
So Request.Cookies and Response.Cookies make perfect sense.
Both objects Request and Response "live" in the server. So Request holds the data sent by the User Agent (the Browser, like Chrome, IE, etc.). Examples of this data are, the POST and GET Variables, the User Agent, the language, IP Adress, and many more.
Response is the object that lets you send data to the User Agent (the browser), i.e. a Web Page, a stream of bytes (like a downloadable file), etc.
The cookies live in the client side, that's right, but is the browser that send this information, so this data comes in the Request object.
You receive the cookies via Request.Cookies, but you receive the cookies in the Server. If you are coding in C#, the code is in the Server point of view, so receive means, the server receives. If you want to access the cookies in the Client Side, you must use some client programming language like JavaScript.
I hope this helps.
I have a Jquery Ajax request which goes to Facebook server. (jsonP)
However , Im not satisfy with the current response and I would like to "edit" the response before it goes back to the ajax call.
In order to do it , I was thinking about building a proxy by ashx. ( it will do the request , and when the response is back - he will edit it , and it will return to the ajax call).
jQuery ajax ---> myHandler.ashx ----> Facebook +--->
|
|
jQuery ajax <---- myHandler.ashx(+edit) <-----------+
the problem is that Facebook requires its cookies , And IMHO -only facebook can access its cookies.
Is there any way for the ashx handler to be able to TRANSFER the cookie along with his request ( as if jQuery ajax would do ) ?
Technically, you may simulate a cookie-aware user agent and relay them to user.
Request 1:
Browser sends the first request to your ashx handler.
Your handler relays it to facebook server.
FB responds with a content + a set-cookie header(s) (fb-cookie=xxx on facebook.com)
Your handler edits the content and returns the set-cookie header with some kind of prefix (your-fb-cookie=xxx on yoursite.com)
Request 2:
Next time the browser sends a request to your ashx handler, you will receive the the "your-fb-cookie=xxx" (as it is defined on yoursite.com)
Your handler relays the request to FB with the cookie "fb-cookie=xxx"
...
However, be aware that facebook (or any other service) may (and should) use some kind of anti-flood detection.
It may block your server's IP adress as it receives lots of requests from it.
This can even be against FB licensing terms.
If you visit an aspx web form, and click the submit button causing a POST to the server, then click submit again causing a second POST before receiving a response from the first POST, what happens in terms of the response? Does the server process both requests simultaneously or serially? Does the server send both responses? Does the browser ignore one of the responses? This may be self explanatory after an answer to the previous questions, but if I were to call Response.Clear(); Response.End(); for the second request, what would happen on the browser end?
If there are no special means at the server side to handle multiple POSTs, the server will handle both requests independently. Whether or not the processing is concurrent - it depends:
if your first POST causes the whole page to reload then it is impossible to trigger the second POST before the page is processed at the server side (because your second click is made from the page which is already at the client side)
if your first POST causes an AJAX POST to the server and the processing takes some time at the server then it is possible that you end up with two POSTS from the same page processed concurrently at the server side
The server always sends responses and browsers do not ignore them. It is your code, at the server side or at the client side, to prevent such unintended multiple POSTs, for example by 302ing the response to another location which doesn't allow the user to rePOST the form.
Specifically, if you just clear the response (send an empty content) and the content type is text/html then the browser will render an empty page.
I would say just about any of those things could happen, depending on the exact timing.
I believe calling Response.Clear(); Response.End(); on the second request would cause an empty response which the browser would receive, possibly after receiving the results of the first request.
Note: we are using lib_neon on client side and Tomcat and servlet api on server side.
The problem is following: when client wants to put some content, it performs a PUT request with an "Expect: 100-continue" header, Tomcat handles it by simply returning status 100 Continue and after that client starts to send the remaining part of request, and it gets processed by our custom Filters and often it doesn't pass (for instance user is not authorized, or tries to put too large file, exceeding users limit, or something else). Filter sends an error response immidetetly, but client reads the response only when the full request body is commited.
It seems that it is impossible to manually send something instead of 100 Continue status, when some check fails, and this behavior is hardcoded into tomcat, is there any other way not to upload request body, when it is impossible?
You need a servlet container with a more sane 100-continue handling (I believe jetty qualifies).
I can't believe this clarification still isn't part of the servlet spec; I believe I asked for it something like 7 years ago.