What is the difference between the Response object and Request object in ASP?
Generally, the request object is going to hold information about the current user request, that is the client browser requesting a webpage from your server. The response object contains the response data that will be sent back to the user. Think of it in terms of a http request/response cycle. The objects hold the respective data.
The ASP Request object is used to get information from a visitor.
Usually, you read the contents of the request to determine the course of action and the proper response.
The ASP Response object is used to send output to the user from the server.
Request Object: is used to read the data submitted by the client (i.e. the data comes with the client request)
Response Object: is used to send instructions to the client browser.
This might help you further.
Request object: from client (you) to server.
Response object: from Server to client (you) rendering back to the service.
These objects are called intrinsic object of ASP.Net.
Request Object:
Used to send information to the clients.
Response Object:
Used to retrieve information included with the request from server.
Related
I have read many discussions on this, such as the fact the PUT is idempotent and POST is not, etc. However, doesn't this ultimately depend on how the server is implemented? A developer can always build the backend server such that the PUT request is not idempotent and creates multiple records for multiple requests. A developer can also build an endpoint for a PUT request such that it acts like a DELETE request and deletes a record in the database.
So my question is, considering that we don't take into account any server side code, is there any real difference between the HTTP methods? For example, GET and POST have real differences in that you can't send a body using a GET request, but you can send a body using a POST request. Also, from my understanding, GET requests are usually cached by default in most browsers.
Are HTTP request methods anything more than just a logical structure (semantics) so that as developers we can "expect" a certain behavior based on the type of HTTP request we send?
You are right that most of the differences are on the semantic level, and if your components decide to assign other semantics, this will work as well. Unless there are components involved that you do not control (libraries, proxies, load balancers, etc).
For instance, some component might take advantage of the fact that PUT it idempotent and thus can re retried, while POST is not.
The Hypertext Transfer Protocol (HTTP) is designed to enable communications between clients and servers.
HTTP works as a request-response protocol between a client and server.
A web browser may be the client, and an application on a computer that hosts a web site may be the server.
Example: A client (browser) submits an HTTP request to the server; then the server returns a response to the client. The response contains status information about the request and may also contain the requested content.
HTTP Methods
GET
POST
PUT
HEAD
DELETE
PATCH
OPTIONS
The GET Method
GET is used to request data from a specified resource.
GET is one of the most common HTTP methods.
Note that the query string (name/value pairs) is sent in the URL of a GET request.
The POST Method
POST is used to send data to a server to create/update a resource.
The data sent to the server with POST is stored in the request body of the HTTP request.
POST is one of the most common HTTP methods.
The PUT Method
PUT is used to send data to a server to create/update a resource.
The difference between POST and PUT is that PUT requests are idempotent. That is, calling the same PUT request multiple times will always produce the same result. In contrast, calling a POST request repeatedly have side effects of creating the same resource multiple times.
The HEAD Method
HEAD is almost identical to GET, but without the response body.
In other words, if GET /users returns a list of users, then HEAD /users will make the same request but will not return the list of users.
HEAD requests are useful for checking what a GET request will return before actually making a GET request - like before downloading a large file or response body.
The DELETE Method
The DELETE method deletes the specified resource.
The OPTIONS Method
The OPTIONS method describes the communication options for the target resource.
src. w3schools
We know the difference between POST and GET, but why should a client state the method type when issuing http requests? Why should it make a difference for the server? in the end, it is the server job to deal with those requests according to their URL and Content. either by redirecting, blocking or accepting and using data (existing in the URL or request body).
An endpoint can accept both GET and POST requests (along with PUT, PATCH and DELETE). If the client does not explicitly state what type of request they are sending, the server will interpret it as a GET request (the default).
Consider the following PHP example, sitting on https://api.example.com/resources/:
<?php
if ($_POST["request"]) {
// Create new resource
}
else if ($_GET["request"]) {
// List existing resources
}
In both instances, the request parameter is sent to the same page, and different logic is run based on what the method is. But considering the same data is sent to the same page in both instances, the server wouldn't know which one of the two conditions to step into if the client doesn't explicitly specify the method.
In RESTful programming, both the client and server have been programmed to understand the request, but the client has no knowledge of the server itself. It is up to the server to process the request, based off of what the client asks it to do. And the client asks it to do different things by specifying the method.
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.
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.
When using ASP.Net Ajax to call PageMethods, how can I access the Http response headers from the "success" method?
For example:
PageMethods.DoSomething(
function(result){successMethod(result)},
function(error){errorMethod(error)}
);
function successMethod(result){
//------how can I access the Http response headers from here? ------
}
Thanks for any help
In your example, PageMethods.DoSomething should have a return value equal to WebRequest if it's an asp.net web service proxy. This is provided so that you can manipulate the request after you've initiated it (i.e. cancel it etc).
With this class you have an add_completed method which you can use to add a handler for when the web request completes. The signature for the callback is function OnWebRequestCompleted(executor, eventArgs), and the executor parameter in this enables you to get hold of extra response information. For example, you can get hold of the response headers with executor.getAllResponseHeaders(); which should be a map (named collection) of header names and values.
So if you add a handler to the web request's completed event immediately after making the service method call, it should work (there's no web service in the world that can respond faster than two consecutive lines of code!).
The previous hyperlink to WebRequest contains a full example of how wire this up. Notice, however, that this code uses the WebRequest directly.
Asp.Net Ajax Web Service proxy classes use the WebServiceProxy class, and each proxy method ultimately call its invoke method, which returns the WebRequest instance.
A web request has a headers collection
http://msdn.microsoft.com/en-us/library/bb383774.aspx
The webrequestmanager is a static object that you may be able to extract this information from:
http://msdn.microsoft.com/en-us/library/bb397435.aspx
Hopefully, between the two links, it makes sense :-;
I'm not saying recode to use this necessarily, but page methods is a wrapper and as such I think it would access information from a web request, which can be affected from the WebRequestManager...