I have seen that that one of the main difference between POST and GET is that POST is not cached but GET is cached.
Could you explain me what do you mean about "cache"?
Also, if I use POST or GET server sends me response. Is there any difference? In all of cases, I have request data and response, is not it?
Thanks
To Cache (in the context of HTTP) means to store a page/response either on the client or some intermediate host - perhaps in a content distribution network. When the client requests a page, then the page can be served from the client's cache (if the client requested it before) or the intermediate host. This is faster and requires fewer resources than getting the page from the server that generated it.
One downside is that if the request changes some state on the server, that change won't happen if the page is served from a cache. This is why POST requests are usually not served from a cache.
Another downside to caching is that the cached copy may be out of date. The HTTP caching mechanisms try to prevent this.
The basic idea behind the GET and POST methods is that a GET message only retrieves information but never changes the state of the server. (Hence the name). As a result, just about any caching system will assume that you can remember the last GET response returned, and that the next one will look the same.
A POST on the other hand is a request that sends new information to the server. So not only can these not be cached (because there's no guaruantuee that the next POST won't modify things even more; think +1 like buttons for example) but they actually have to invalidate parts of the cache because they might modify pages.
As a result, your browser for example will warn you when you try to refresh a page to which you POSTed information, because you might make changes you did not want made by doing so. When GETting a page, it will not do so because you cannot change anything on the site by doing so.
(Or rather; it's your job as a programmer to make sure that nothing changes when GETting a page.)
GET is supposed to return the same result from the server and not change things at the server side and hence idempotent.
Whereas POST means it can modify something at the server(make an entry in db, delete something etc) and hence not idempotent.
And with regards to caching the data in GET has been addressed here in a nice manner.
http://www.ebaytechblog.com/2012/08/20/caching-http-post-requests-and-responses/#.VGy9ovmUeeQ
Related
Is there a specific scenario where we use a POST instead of GET, to implement the functionality of get operation ?
GET is supposed to get :) and POST is used to mainly add something new or sometimes often used for updates as well (although PUT is recommended in such scenarios). There is no specific scenario where we use a POST instead of a GET, if we require this, that means we are probably doing it wrong, although nothing stops you doing this but this is bad design and you should take a step back and plan your API carefully.
There are 2 important cases for a POST i.e. POST is more secure than a GET and POST can send large amount of data but even with this I won't recommend why one will use POST to simulate a GET behaviour.
Lets understand usage of get and post :
What is GET Method?
It appends form-data to the URL in name/ value pairs. The length of the URL is limited by 2048 characters. This method must not be used if you have a password or some sensitive information to be sent to the server. It is used for submitting the form where the user can bookmark the result. It is better for data that is not secure. It cannot be used for sending binary data like images or word documents. It also provides $_GET associative array to access all the sent information using the GET method.
What is POST Method?
It appends form-data to the body of the HTTP request in such a way that data is not shown in the URL. This method does not have any restrictions on data size to be sent. Submissions by form with POST cannot be bookmarked. This method can be used to send ASCII as well as binary data like image and word documents. Data sent by the POST method goes through HTTP header so security depends on the HTTP protocol. You have to know that your information is secure by using secure HTTP. This method is a little safer than GET because the parameters are not stored in browser history or in web server logs. It also provides $_POST associative array to access all the sent information using the POST method.
Source: https://www.edureka.co/blog/get-and-post-method/
So both the methods have their specific usage.
POST method is used to send data to a server to create or update a resource.
GET method is used to request data from a specified resource.
If you want to fetch some data you can use the GET method. But if you want to update an existing resource or create any new resource you should use POST. GET will not help you to create/update resources. So exposing the api should be specific to your needs.
UPDATE
So your main question is in what scenario we can use POST to implement the functionality of GET.
To answer that, as you understand what GET and POST does, so with GET request you will only fetch the resource. But with POST request you are creating or updating the resource and also can send the response body containing the form data in the same request response scenario. So suppose you are creating a new resource and the same resource you want to see, instead of making a POST call first and making a GET call again to fetch the same resource will cost extra overhead. You can skip the GET call and see your desired response from the POST response itself. This is the scenario you can use POST instead of making an extra GET call.
There is a RequestMethod named PATCH.
To use this method, we can define #PatchMapping for a rest endpoint.
As per my understanding, it sounds like partially updating the DB object.
Generally, we use POST or PUT calls to perform save or update. So, still not clear what are exact use cases of PatchMapping and why can't I just use PUT instead of PATCH?
still not clear what are exact use cases of PatchMapping and why can't I just use PUT instead of PATCH?
PUT (defined by RFC 7231) and PATCH (defined by RFC 5789) are two different methods used for a similar purpose: to request that the server make its representation of a resource match the representation on the client.
Imagine, if you would, trying to update a web page provided by a server. The client first obtains a recent copy of the server's representation:
GET /foo
and then, using the client's favorite local HTML editor, makes changes to this private copy. When the client has finished making the changes, we want to send those changes back to the server to be used.
The straight forward way to do this in HTTP is to simply send the entire updated representation back to the server:
PUT /foo
<html>....</html>
When the representation is very large (compared with the HTTP headers), and the edits are very small (compared to the document), then PUT becomes a somewhat "expensive" way to achieve what ought to be a small thing.
To that end, we might also support PATCH, so that instead of sending the entire document, we just send a representation of the changes we made: a patch document.
When the server receives our patch, it loads its own copy of the document, applies the changes described by the patch document, and saves the result.
Thus: the overall use case is the same: remote authoring. You load a representation of a resource into your HTTP aware document editor, make a few changes, and hit "save", and your editor knows what to do to communicate your edits back to the server.
Assume I have a single servlet in a web app, and all users need to be logged in before they can do anything. So in the get and post methods there is an if block to test if the user is logged by trying to extract a session attribute in to process request, and else to redirect to login page if not logged in.
Given this scenario, is there a way an intruder can manipulate the system to gain entry without knowing the password? Assume the password is hard-coded into the servlet. If yes, where would he start?
I would look at http://docs.oracle.com/javaee/5/tutorial/doc/bncbe.html#bncbj and the section linked from that section about specifying authentication mechanisms.
See also (on Stackoverflow) Looking for a simple, secure session design with servlets and JSP and How do servlets work? Instantiation, sessions, shared variables and multithreading
In short, you don't need to do much yourself about checking for a session attribute if you use the mechanisms described on those pages. Your login form can be used in the 'form-login' configuration requiring authentication.
The key of security is around your comment extract a session attribute -- how are you doing this? Are they sending you a query string param? Are they sending you credentials in the method headers?
To #Hogan's point, unless this is over HTTPS the answer is: "No, it is not secure. A man-in-the-middle (MITM) can get the password from your submission and simply re-use it to mask its own nefarious requests".
If the communication IS done over HTTPS, then you should be fine. Having a single hard-coded password is fine, but consider the case where the password gets compromised; now every single client/user/etc. has to change their code.
A better design is to issue clients a key they can send along with their requests that you can use to identify who they are and if a key gets compromise, re-issue a new one to that user/client/etc.
This assumes traffic is over HTTPS
If traffic is not, a lot of this breaks down and you need to look at things like HMAC's. I wrote this article on designing secure APIs -- it should give you a good introduction to how all this nightmare of security works.
If your eyes are rolling into the back of your head and you are thinking "My god, I just wanted a YES/NO", then my recommendation is:
Require all traffic to be over HTTPS
Issue individual passwords to each client so if one gets compromised, every single one isn't compromised.
That should get you pretty far down the road.
Hope that help. This topic is super hairy and I know you didn't want a history lesson and just want to solve this question and move forward. Hope I gave you enough to do that.
If user refresh the page continuously using F5 functional key then the page loading is very slow and can be seen blank page for long time.
How to solve this problem?
I tried using cache on server side but I don't think that I am using it in proper way.
Can somebody help me with an example.
I think you need to use browser cache, which can be controlled by http headers, or meta tags.
http://www.mnot.net/cache_docs/
You need to set page cache to be around 5 seconds or some similar value so that no new request will be sent to server in that time interval.
A few things:
You could try to minimize processing time within your application, maybe by minimizing wasteful operations. Sounds like your application spends a lot of time recreating the output.
You could try to add some sort of caching on the server side, and and send the user the same page (ie no "new" processing) for some time. Depending on the mechanism, this may not be feasible though (https, security?). At least, afaik.
Of course you could change the way the site works. You could use Ajax to push information to the site the user is on, and so take the urge to refresh away from him.
And maybe your server just does not have enough power to serve a lot of users at the same time?
It is very difficult to stop user from pressing F5.
Try making your code more optimized.
Use meta tags for cache like:
cache-control
EXPIRES
PRAGMA NO-CACHE
Also check this for JSP caching.
response.setIntHeader("Refresh",5);
just use this jsp method for autorefreeshing of ur webpage...
http://www.tutorialspoint.com/jsp/jsp_auto_refresh.htm
I've already read most of the questions regarding techniques to prevent form spam, but none of them seem to suggest the use of the browser's session.
We have a form that sends an email to given email address and we didn't like the idea of using "captchas" or Javascript, as we wanted to keep the user journey simple and accessible to those without Javascript.
We would like to use the session object to help prevent form spam. Our webapp is developed on Weblogic Server 10 using Struts.
The solution being, when the form loads, it would set a variable in the session object. Once you click submit, we check if the session for the variable. No variable, redirect to the form. Variable exists send the email.
I would really appreciate any opinions/reasons why this might be a bad idea, so we can evaluate this solution against others.
Many thanks,
Jonathan
There is nothing to prevent a spammer from automating the process of downloading your form (thus generating the cookie) and submitting it. It may impose a slight burden on the spammer, but a trivial one.
As an example, a form can be easily downloaded and submitted, with cookies preserved, using a command-line tool such as cURL. This can then be run from a script repeatedly.
Session objects can, depending on implementation, be relatively heavy in terms of resource usage, as well as somewhat slow. Additionally, the spammer, if they realize how you are blocking them, can simply start a new session every time they hit the form by not sending back the session cookie.
So, because that technique relies on the client to behave nicely, and the expected behavior is fairly easy to prevent, it is possibly less useful than some other ways to solve the problem.
Thank you for your reply cdeszaq, but I'm not sure if you mis-understood my question.
For the form submission to complete successfully, clients will be forced to load the form to set up the session object correctly. Only when the session is in the correct state, will it be possible to send an email.
If the spammer is not sending back the session cookie, then they will not be able to spam my form as they haven't gone to my form page that creates the right session.
I agree that using the session object would create extra resource. Our implementation would simply, (using JSP) call session.setAttribute("formLoaded", true); and in my Struts action I would simply use session.getAttribute("formLoaded"); to check.
I wonder if this might work:
Each time you render page/form, create a random bit of text
Put that text in the session
Include that text as a hidden field in the form
User submits the form
Action compares the hidden text to the value in the session - if there's a match, send the email
Since a hacker wouldn't be able to put any random value in the session, they wouldn't be able to spam. Right?