Why NOT use POST method here?_问答_开发者_运维开发者技术经验分享

I have a classifieds website.

In the main page (index) I have several form fields which the user may or may not fill in, in order to specify a detailed search of classifieds.

Ex:

   Category: Cars
   Price from: 3000
   Price to:   10000
   Color: Red
   Area: California

The forms' action is set to a php page:

   <form action='query_sql.php' method='post'>

In query_sql.php I fetch the variables like this:

   category=$_POST['category'];
   etc etc...

Then query MySql:

   $query="SELECT........WHERE category='$category' etc etc....
   $results = mysql_query($query);

Then I simply display the results of the query to the user by creating a table which is filled in dynamically depending on the results set.

However, according to an answer by Col. Shra开发者_JAVA技巧pnel in my previous Q I shouldn't use POST here: How to hide URL from users when submitting this form?

The reason I use post is simply to hide the "one-page-word-document" long URL in the browsers adress bar.

I am very confused, is it okay to use POST or not?

It is working fine both when I use GET or POST now... And it is already on a production server...

Btw, in the linked question, I wasn't referring to make URL invisible (or hide it) I just wanted it too look better (which I have accomplished with mod_rewrite).

UPDATE:

If I use GET, then how should I make the url better looking (beautiful)? Check this previous Q out:

How to make this very long url appear short?

Search engines won't index the results
People can't bookmark searches
People can't send a link to their searches to their friends
People can't link to results page from their own webpages
Some people can't go Back to the page without receiving scary "Do you want to resubmit the form?"

If I use GET, then how should I make the url better looking (beautiful)?

You shouldn't. It doesn't matter. The number of users who would notice the URL the form submitted to is tiny, and the number who care is even smaller.

You probably want to perform some vetting on the user inputs to mitigate against SQL injection attacks as it looks like the input is directly manipulating the SQL statement

The idea behind using GET over POST is that using GET, you have a search URL that you can modify in the address bar, bookmark, and pass on.

Technically, both methods are fine ~~and basically interchangeable~~ if you have no need to address these aspects, and are passing data from one page to the next.

One big difference between GET and POST is that GET parameters shouldn't exceed 1-2 kilobytes in size. The size limit for POST request is usually in the dozens of megabytes.

GET should be used for requests which are either read-only or don't have any side-effects on the data (i.e. they should be idempotent, as mentioned in the HTTP documentation). You should be able to submit a GET request as many times as you want without it affecting what results will be returned. (You may not always get the same result though, since something else may have changed in the meantime of course, but the GET request shouldn't change the data itself).

So searching comes under this category, since you shouldn't be changing any data on your system which will affect the output when you search, you're just giving data to the user based on some parameter they're giving you.

Of course some data you will always want to be updated, such as statistics (as mentioned in the comments), and this is fine with GET, as it won't affect the response, it's just to keep a record of all the requests made, etc.

POST should be used when any destructive action is performed (by destructive, I mean when data is changed.. not just delete). So add, update, delete, etc.

This is why a browser will usually prompt you if you want to resubmit a POST request, but not for GET. It's because POST is meant to be used when data is going to be changed.

Also, some browsers can pre-fetch the pages from links on your page (to try and give the illusion of speed when a link is eventually clicked). If the GET action does something destructive (such as delete a record), then this could be inadvertently triggered simply by visiting the page the link is on for example.

If you're worried about your URLs looking "messy", you can use something like mod_rewrite to make the URLs more human friendly. So "http://yoursite.com/search/cars/red" could map to "http://yoursite.com/search.php?category=cars&color=red" for example.

First of all remember to sanitize your input using mysql_real_escape_string. GET vs POST is practically the same except that:

With POST you can't bookmark the page
With GET you can't post files and there's a length limit on the query string

I use POST only when I know that the page will modify something server side (i.e. DB update) and then do a redirect to another page.

David Dorward's answer addresses most of the points - however a big one he misses out is the issue of cacheability.

POST and GET have very specific semantics - POST should mean the request changes the data on the system, while GET does NOT. Therefore the response to a POST should not be cached. But the response to a GET may be cached (depending on the headers sent).

NB content is not just cached on the browser.

It sounds like you're concerned with not-friendly URLs, i.e., you want to have friendly URLs throughout your site/application. If so, you can continue to use POST in your scenario, but do a redirect after POST. By doing a redirect-after-post, the redirected URL which renders the results of your search can be made friendly and short, while you can use POST to pass more parameters in the request to the server and avoid the long query string associated with the GET URL.

To learn more redirect-after-post, check out this article http://www.theserverside.com/news/1365146/Redirect-After-Post

Did you consider:

Submitting the form via GET (or POST), then server-side read the contents of the form (from the url or post data), form a nice url, then 301-redirect to that url.

That way you have complete control of the URL (e.g. its not up to the browser/form how the url looks), and you get all the benefits of using GET, e.g. bookmarkable, linkable, back-button friendly, etc.