Re: POST v. GET

And, if you don't care if the data comes from POST or GET (or COOKIE), then you can use the superglobal $_REQUEST as it contains a mix of data from all three. http://www.example.com/foo.php?aname=leston print $_REQUEST['aname']; Which is similar to import_request_variables(). http://www.php.net/manual/en/language.variables.predefined.php http://www.php.net/import_request_variables Regards, Philip Olson On Thu, 20 Jun 2002, Erik Price wrote: > To add to Chris Shiflett's excellent overview of GET vs POST: > > "HTTP Made Really Easy" > http://www.jmarshall.com/easy/http/ > > > after you read this web page (take you no more than 15 minutes), you > should consider browsing the actual HTTP spec, though it's pretty > technical and is very long. > > > > Erik > > > > On Wednesday, June 19, 2002, at 06:57 PM, Chris Shiflett wrote: > > > GET and POST are two different request methods in HTTP. It is a common > > misconception that the only significance of these terms is that they > > are the valid options of the "method" attribute in an HTML form. > > Unfortunately, searching the Web for the answer to this question might > > yield incomplete results. It would be better to find a book on HTTP to > > get the real answer, but I can give an overview here. > > > > The GET method is by far the most popular request method used in HTTP > > requests. It is a simple request for a resource located on the Web. The > > simplest request might look something like this: > > > > GET / HTTP/1.0 > > > > Or, in HTTP/1.1, since the Host header is required: > > > > GET / HTTP/1.1 > > Host: www.php.net > > > > There is no content sent in a GET request. This is the type of request > > your browser will send a Web server when you click on a link or type a > > URL into the address bar, among other things. > > > > With the POST method, the HTTP client sends content along with the > > request in URL encoded format. A POST request might look something like > > this: > > > > POST / HTTP/1.1 > > Host: www.php.net > > Content-Type: application/x-www-form-urlencoded > > Content-Length: 26 > > > > fname=chris&lname=shiflett > > > > In this request, the browser is sending data to the Web server. This is > > very similar to the way the server sends content back the the client. > > > > How does this apply to HTML forms? Well, when a method of GET is used, > > the browser will use the GET request to request the page designated by > > the "action" attribute of the form. The form fields will be included as > > name/value pairs in the URL. This is especially useful when you want > > the user to be able to bookmark the results page, email the URL to a > > friend, etc. This is how Google's search works. If you'll notice, you > > can bookmark search results, and each time you visit the bookmark, > > you'll be given the current results of that search. The browser won't > > prompt you to reload the page. > > > > GET has disadvantages as well. One is that depending on lengthy URLs is > > dangerous. Apache has had, at least in the past, a hard upper limit of > > 1024 bytes in a URL. Browsers vary in the length of a URL they can > > support. The W3C warns against depending on more than 255 bytes. > > Another disadvantage of GET is that the data is included in the URL. If > > sensitive information is included, not only can it be sniffed (a > > vulnerability of POST also), but it can also be bookmarked, found in a > > browser's history, seen by someone passing by, etc. If the request was > > to log someone in, it would be possible to log in as that user simply > > by visiting the URL. Even using SSL would not guard against these types > > of vulnerabilities. > > > > For many cases, it is preferable to use POST. When used in combination > > with SSL, POST can provide a robust (no danger of having too much data) > > and secure (the data will be encrypted in the SSL communication) method > > for communicating data back to the server. This is what you will find > > on forms where you are submitting a credit card number, for example. > > > > As you can see, each method has its own advantages and disadvantages. > > Many people do not take the time to really understand what these two > > methods offer and will say, "just always use POST" or something of that > > nature. Others will cite the differences in these methods by describing > > how to receive the data in your server-side logic, but this also misses > > the point. > > > > That should give you a general idea. Like I said, a good book on HTTP > > will help you much more. > > > > Chris > > > > Leston Drake wrote: > > > >> Hi all, > >> > >> Can someone explain the difference between POST and GET for me? > >> > >> TIA, > >> Leston > >> > >> > > > > > > > > -- PHP General Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > > > ---- > > Erik Price > Web Developer Temp > Media Lab, H.H. Brown > pricee@hhbrown.com > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >