How can I save the client's complete address in asp application? Actually I want to send a response multiple times to same client without new call request by him. I don't want to end the response, when he called first time a service.
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?
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.
I am using httpClient.addInterceptor(logging); to log every requests made before it is being sent to the server.
But, I have to use those requests to be saved as a string for my generous purpose. If it is possible than how can I implement it?
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.
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.