What is the conceptual difference between forward() and sendRedirect()?
In the web development world, the term "redirect" is the act of sending the client an empty HTTP response with just a Location header containing the new URL to which the client has to send a brand new GET request. So basically:
Client sends a HTTP request to some.jsp.
Server sends a HTTP response back with Location: other.jsp header
Client sends a HTTP request to other.jsp (this get reflected in browser address bar!)
Server sends a HTTP response back with content of other.jsp.
You can track it with the web browser's builtin/addon developer toolset. Press F12 in Chrome/IE9/Firebug and check the "Network" section to see it.
Exactly the above is achieved by sendRedirect("other.jsp"). The RequestDispatcher#forward() doesn't send a redirect. Instead, it uses the content of the target page as HTTP response.
Client sends a HTTP request to some.jsp.
Server sends a HTTP response back with content of other.jsp.
However, as the original HTTP request was to some.jsp, the URL in browser address bar remains unchanged. Also, any request attributes set in the controller behind some.jsp will be available in other.jsp. This does not happen during a redirect because you're basically forcing the client to create a new HTTP request on other.jsp, hereby throwing away the original request on some.jsp including all of its attribtues.
The RequestDispatcher is extremely useful in the MVC paradigm and/or when you want to hide JSP's from direct access. You can put JSP's in the /WEB-INF folder and use a Servlet which controls, preprocesses and postprocesses the requests. The JSPs in the /WEB-INF folder are not directly accessible by URL, but the Servlet can access them using RequestDispatcher#forward().
You can for example have a JSP file in /WEB-INF/login.jsp and a LoginServlet which is mapped on an url-pattern of /login. When you invoke http://example.com/context/login, then the servlet's doGet() will be invoked. You can do any preprocessing stuff in there and finally forward the request like:
request.getRequestDispatcher("/WEB-INF/login.jsp").forward(request, response);
When you submit a form, you normally want to use POST:
<form action="login" method="post">
This way the servlet's doPost() will be invoked and you can do any postprocessing stuff in there (e.g. validation, business logic, login the user, etc).
If there are any errors, then you normally want to forward the request back to the same page and display the errors there next to the input fields and so on. You can use the RequestDispatcher for this.
If a POST is successful, you normally want to redirect the request, so that the request won't be resubmitted when the user refreshes the request (e.g. pressing F5 or navigating back in history).
User user = userDAO.find(username, password);
if (user != null) {
request.getSession().setAttribute("user", user); // Login user.
response.sendRedirect("home"); // Redirects to http://example.com/context/home after succesful login.
} else {
request.setAttribute("error", "Unknown login, please try again."); // Set error.
request.getRequestDispatcher("/WEB-INF/login.jsp").forward(request, response); // Forward to same page so that you can display error.
}
A redirect thus instructs the client to fire a new GET request on the given URL. Refreshing the request would then only refresh the redirected request and not the initial request. This will avoid "double submits" and confusion and bad user experiences. This is also called the POST-Redirect-GET pattern.
See also:
How do servlets work? Instantiation, sessions, shared variables and multithreading
doGet and doPost in Servlets
How perform validation and display error message in same form in JSP?
HttpServletResponse sendRedirect permanent
requestDispatcher - forward() method
When we use the forward method, the request is transferred to another resource within the same server for further processing.
In the case of forward, the web container handles all processing internally and the client or browser is not involved.
When forward is called on the requestDispatcherobject, we pass the request and response objects, so our old request object is present on the new resource which is going to process our request.
Visually, we are not able to see the forwarded address, it is transparent.
Using the forward() method is faster than sendRedirect.
When we redirect using forward, and we want to use the same data in a new resource, we can use request.setAttribute() as we have a request object available.
SendRedirect
In case of sendRedirect, the request is transferred to another resource, to a different domain, or to a
different server for further processing.
When you use sendRedirect, the container transfers the request to the client or browser, so the URL given inside the sendRedirect method is visible as a new request to the client.
In case of sendRedirect call, the old request and response objects are lost because it’s treated as new request by the browser.
In the address bar, we are able to see the new redirected address. It’s not transparent.
sendRedirect is slower because one extra round trip is required, because a completely new request is created and the old request object is lost. Two browser request are required.
But in sendRedirect, if we want to use the same data for a new resource we have to store the data in session or pass along with the URL.
Which one is good?
Its depends upon the scenario for which method is more useful.
If you want control is transfer to new server or context, and it is treated as completely new task, then we go for sendRedirect.
Generally, a forward should be used if the operation can be safely repeated upon a browser reload of the web page and will not affect the result.
Source
The RequestDispatcher interface allows you to do a server side forward/include whereas sendRedirect() does a client side redirect. In a client side redirect, the server will send back an HTTP status code of 302 (temporary redirect) which causes the web browser to issue a brand new HTTP GET request for the content at the redirected location. In contrast, when using the RequestDispatcher interface, the include/forward to the new resource is handled entirely on the server side.
The main important difference between the forward() and sendRedirect() method is that in case of forward(), redirect happens
at server end and not visible to client, but in case of
sendRedirect(), redirection happens at client end and it's visible to
client.
Either of these methods may be "better", i.e. more suitable, depending on what you want to do.
A server-side redirect is faster insofar as you get the data from a different page without making a round trip to the browser. But the URL seen in the browser is still the original address, so you're creating a little inconsistency there.
A client-side redirect is more versatile insofar as it can send you to a completely different server, or change the protocol (e.g. from HTTP to HTTPS), or both. And the browser is aware of the new URL. But it takes an extra back-and-forth between server and client.
SendRedirect() will search the content between the servers. it is slow because it has to intimate the browser by sending the URL of the content. then browser will create a new request for the content within the same server or in another one.
RquestDispatcher is for searching the content within the server i think. its the server side process and it is faster compare to the SendRedirect() method. but the thing is that it will not intimate the browser in which server it is searching the required date or content, neither it will not ask the browser to change the URL in URL tab. so it causes little inconvenience to the user.
Technically redirect should be used either if we need to transfer control to different domain or to achieve separation of task.
For example in the payment application
we do the PaymentProcess first and then redirect to displayPaymentInfo. If the client refreshes the browser only the displayPaymentInfo will be done again and PaymentProcess will not be repeated. But if we use forward in this scenario, both PaymentProcess and displayPaymentInfo will be re-executed sequentially, which may result in incosistent data.
For other scenarios, forward is efficient to use since as it is faster than sendRedirect
Request Dispatcher is an Interface which is used to dispatch the request or response from web resource to the another web resource. It contains mainly two methods.
request.forward(req,res): This method is used forward the request from one web resource to another resource. i.e from one servlet to another servlet or from one web application to another web appliacation.
response.include(req,res): This method is used include the response of one servlet to another servlet
NOTE: BY using Request Dispatcher we can forward or include the request or responses with in the same server.
request.sendRedirect(): BY using this we can forward or include the request or responses across the different servers. In this the client gets a intimation while redirecting the page but in the above process the client will not get intimation
Simply difference between Forward(ServletRequest request, ServletResponse response) and sendRedirect(String url) is
forward():
The forward() method is executed in the server side.
The request is transfer to other resource within same server.
It does not depend on the client’s request protocol since the forward () method is provided by the servlet container.
The request is shared by the target resource.
Only one call is consumed in this method.
It can be used within server.
We cannot see forwarded message, it is transparent.
The forward() method is faster than sendRedirect() method.
It is declared in RequestDispatcher interface.
sendRedirect():
The sendRedirect() method is executed in the client side.
The request is transfer to other resource to different server.
The sendRedirect() method is provided under HTTP so it can be used only with HTTP clients.
New request is created for the destination resource.
Two request and response calls are consumed.
It can be used within and outside the server.
We can see redirected address, it is not transparent.
The sendRedirect() method is slower because when new request is created old request object is lost.
It is declared in HttpServletResponse.
I have custom authorization handler in web api and when debugging web api i have found that SendAsync method of handler is called twice when post request is made. when get request is made method is executed one time only. I have also noted that request.Headers.Authorization is null first time and it contains value on second time. I have also noticed that when i remove authorization header form jquery ajax post request then method is called one time only. and fiddler also shows request as POST. but when i add header than first request is sent as OPTIONS /Product/Create HTTP/1.1 and second request as POST /Product/Create HTTP/1.1 in fiddler. anybody have idea why it is happening? and i am making cross domain request.
It is called a CORS pre-flight request. It is a security mechanism that allows a server the ability to grant a client the rights to perform a cross domain request.
When i make an ajax call to server the full page is not postback, only few amount of data goes to the server and return a response page.
But i am wondering about processing. How the Server or server code knows whether the request in normal call or Ajax call.
I request to experts, please clear my doubt.
Thanks in advance.
How the Server or server code knows whether the request in Normal call or Ajax call.
The server knows this if your javascript code marks the HTTP packet as such. E.g. in jQuery the HTTP header sent to the server has an X-Requested-With set and ASP.NET uses this to distinguish if HTTP packets are ajax calls or not.
To know more about HTTP packets you can inspect the ones sent either in a packet sniffer such as Fiddler or in a browser with dev. tools that monitors traffic. In the latter case you can see this in e.g. Chrome dev tools by doing the following:
Open up Chrome Developer Tools, Ctrl+Alt+I (or Cmd+Alt+I in Mac).
Select the Network tab (you may have to refresh the page to enable network monitoring)
Perform the Ajax call, the HTTP request made should show up in the list at the bottom.
Select the relevant packet, you should now see "Headers", "Preview", "Response", "Cookies" and "Timing" tabs for the selected packet.
Select the "Headers" tab
You may have to expand the Request Headers part. Among the headers should be X-Requested-With: XMLHttpRequest
Here is a screenshot of the tool looking at packages as I was editing this answer:
Note that ajax calls don't necessarily have to be asynchronous as they can be synchronous (blocking the javascript until response is loaded) as well. Synchronous calls are necessary sometimes, e.g. popup blockers don't allow you to open a browser window inside an asynchronous ajax callback.
How the Server or server code knows whether the request in Normal call or Ajax call
It doesn't. There is nothing about an HTTP request sent by Ajax that is any different from any other HTTP request.
The code that makes the request can do something to make it recognisable (e.g. by adding a query string, by changing the Accept header to something more suitable for the context (such as Accept: application/json) or by adding additional HTTP headers (some libraries add X-Requested-With: XMLHttpRequest).
None of those are guarantees as someone could always make an HTTP request manually. They are fine for determining which view to return within your own application, but not if you are trying to implement any kind of security.
AJAX calls performs with instance of XmlHttpRequest prototype. 3rd argument of its .open() method is async:bool. So
xhr.open("GET", "http://example.com", true)
is async and
xhr.open("GET", "http://example.com") is sync.
jQuery get(), post() and ajax() is async by default and you need to pass async param to make it synchronous. So answer to your question: YOU tell the browser what request you want.
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 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.