GET or POST method?

Hi,

I have to decide which form-method I should use (GET or POST). I found
the following recomendation:
If the service associated with the processing of a form has side
effects (for example, modification of a database or subscription to a
service), the method should be POST. (http://www.cs.tut.fi/~jkorpela/
forms/methods.html).

However, later I did not find any convinced arguments why it should
help (it can be that I just did not understand something).

So, I have decided not to go into the details of GET and POST methods
and just use POST. Is here any significant difference between GET and
POST which I should worry about (like security issues or something
else)? Or it is just question of convenience?

Re: GET or POST method?

In our last episode,
, the
lovely and talented Kurda Yon broadcast on comp.lang.php:

> So, I have decided not to go into the details of GET and POST methods
> and just use POST. Is here any significant difference between GET and
> POST which I should worry about (like security issues or something
> else)? Or it is just question of convenience?

URIs for the GET method can be bookmarked, saved as links, and even entered
in other documents as links. In some kinds of reference applications, this
might be highly desirable.

--
Lars Eighner usenet@larseighner.com
Countdown: 371 days to go.

Re: GET or POST method?

Hello,

on 01/15/2008 12:19 AM Kurda Yon said the following:
> Hi,
>
> I have to decide which form-method I should use (GET or POST). I found
> the following recomendation:
> If the service associated with the processing of a form has side
> effects (for example, modification of a database or subscription to a
> service), the method should be POST. (http://www.cs.tut.fi/~jkorpela/
> forms/methods.html).
>
> However, later I did not find any convinced arguments why it should
> help (it can be that I just did not understand something).
>
> So, I have decided not to go into the details of GET and POST methods
> and just use POST. Is here any significant difference between GET and
> POST which I should worry about (like security issues or something
> else)? Or it is just question of convenience?

I think with GET you are limited to sending with no more than 255
characters. Above that the browser may chop your submission URL.

--

Regards,
Manuel Lemos

PHP professionals looking for PHP jobs
http://www.phpclasses.org/professionals/

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

Re: GET or POST method?

On Tue, 15 Jan 2008 Kurda Yon wrote:
> Hi,
>
> I have to decide which form-method I should use (GET or POST). I found
> the following recomendation:
> If the service associated with the processing of a form has side
> effects (for example, modification of a database or subscription to a
> service), the method should be POST. (http://www.cs.tut.fi/~jkorpela/
> forms/methods.html).
>
> However, later I did not find any convinced arguments why it should
> help (it can be that I just did not understand something).
>
> So, I have decided not to go into the details of GET and POST methods
> and just use POST. Is here any significant difference between GET and
> POST which I should worry about (like security issues or something
> else)? Or it is just question of convenience?
>
Use GET when your script is getting information to display to the user.
e.g. A product display get for product id=1, you want to GET the information.

Use POST when you are posting information back to the script to be manipulated
in some fashion.
e.g. Submitting a form with an email for subscription to a newsletter. You
want to POST the information to the script to be handled by a database of
some sort.

D.
--
Superman wears Paul O'Connell pyjamas.

Re: GET or POST method?

Manuel Lemos wrote:
> Hello,
>
> on 01/15/2008 12:19 AM Kurda Yon said the following:
>> Hi,
>>
>> I have to decide which form-method I should use (GET or POST). I found
>> the following recomendation:
>> If the service associated with the processing of a form has side
>> effects (for example, modification of a database or subscription to a
>> service), the method should be POST. (http://www.cs.tut.fi/~jkorpela/
>> forms/methods.html).
>>
>> However, later I did not find any convinced arguments why it should
>> help (it can be that I just did not understand something).
>>
>> So, I have decided not to go into the details of GET and POST methods
>> and just use POST. Is here any significant difference between GET and
>> POST which I should worry about (like security issues or something
>> else)? Or it is just question of convenience?
>
> I think with GET you are limited to sending with no more than 255
> characters. Above that the browser may chop your submission URL.
>

Incorrect. There is no standard, and different browsers handle things
differently. I've seen people pass > 1K in a GET request - although I
definitely do NOT recommend it! :-)

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: GET or POST method?

Kurda Yon wrote:
> Hi,
>
> I have to decide which form-method I should use (GET or POST). I found
> the following recomendation:
> If the service associated with the processing of a form has side
> effects (for example, modification of a database or subscription to a
> service), the method should be POST. (http://www.cs.tut.fi/~jkorpela/
> forms/methods.html).
>
> However, later I did not find any convinced arguments why it should
> help (it can be that I just did not understand something).
>
> So, I have decided not to go into the details of GET and POST methods
> and just use POST. Is here any significant difference between GET and
> POST which I should worry about (like security issues or something
> else)? Or it is just question of convenience?
>
>

Another consideration - GET URLs can be bookmarked. POST URLs cannot.
So, for instance, if you're displaying a restaurant from a list, GET
would be good so the user could bookmark it. But if you're adding data
to a database, you wouldn't want them to add it every time they visit
the page so you'd want to use POST.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: GET or POST method?

Kurda Yon:

> I have to decide which form-method I should use (GET or POST).

http://www.w3.org/2001/tag/doc/whenToUseGet.html

--
Jock

Re: GET or POST method?

Jerry Stuckle wrote:
> Manuel Lemos wrote:
>
>> I think with GET you are limited to sending with no more than 255
>> characters. Above that the browser may chop your submission URL.
>
> Incorrect. There is no standard, and different browsers handle things
> differently. I've seen people pass > 1K in a GET request - although I
> definitely do NOT recommend it! :-)

Although browsers, proxies and servers are free to support URLs of any
length, HTTP/1.1 [1] does explicitly mention 255 characters as the length
above which people ought to exercise caution.

____
1. Hypertext Transfer Protocol -- HTTP/1.1
,
R Fielding, J Gettys et al, 1999.
3.2.1: General Syntax.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 15 days, 23:42.]

GPS & Cameras
http://tobyinkster.co.uk/blog/2008/01/14/gps-cameras/

Re: GET or POST method?

Jerry Stuckle wrote:

> Another consideration - GET URLs can be bookmarked. POST URLs cannot.
> So, for instance, if you're displaying a restaurant from a list, GET
> would be good so the user could bookmark it. But if you're adding data
> to a database, you wouldn't want them to add it every time they visit
> the page so you'd want to use POST.

And another: Login forms should normally be POSTed, so as not to reveal
the password in the browser's address bar.

One more: for file uploads, you'll need to POST.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 15 days, 23:49.]

GPS & Cameras
http://tobyinkster.co.uk/blog/2008/01/14/gps-cameras/

Re: GET or POST method?

David Gillen wrote:
> On Tue, 15 Jan 2008 Kurda Yon wrote:
>> Hi,
>>
>> I have to decide which form-method I should use (GET or POST). I found
>> the following recomendation:
>> If the service associated with the processing of a form has side
>> effects (for example, modification of a database or subscription to a
>> service), the method should be POST. (http://www.cs.tut.fi/~jkorpela/
>> forms/methods.html).
>>
>> However, later I did not find any convinced arguments why it should
>> help (it can be that I just did not understand something).
>>
>> So, I have decided not to go into the details of GET and POST methods
>> and just use POST. Is here any significant difference between GET and
>> POST which I should worry about (like security issues or something
>> else)? Or it is just question of convenience?
>>
> Use GET when your script is getting information to display to the user.
> e.g. A product display get for product id=1, you want to GET the information.
>
> Use POST when you are posting information back to the script to be manipulated
> in some fashion.
> e.g. Submitting a form with an email for subscription to a newsletter. You
> want to POST the information to the script to be handled by a database of
> some sort.
>
> D.

Either method works: a GET method is slightly insecure, in that an
average idiots can fake a URL and maybe get where they shouldn't: Its
harder to do with POST. There you would have to make up a web page form
to submit with POST to the URL you were trying to screw with.

Get is nice because you can use links to get to a GET enabled page..no
need to carate a form or anything.

I tend too use get for simple indexing into a page of data, and POST to
do the real work. Many of my scripts accept both.

Re: GET or POST method?

..oO(The Natural Philosopher)

>Either method works: a GET method is slightly insecure, in that an
>average idiots can fake a URL and maybe get where they shouldn't:

If this can happen, then there's something seriously broken in the
scripts. Even if they can get there, they shouldn't be able to do
anything.

>Its
>harder to do with POST. There you would have to make up a web page form
>to submit with POST to the URL you were trying to screw with.

Not necessarily. There are tools that make it very easy to send
arbitrary POST data to any script. Even the WebDeveloper toolbar in
Firefox has some nice form functions, which allow to change the send
method, to modify hidden or read-only fields before sending etc.

And there are some more things about security to consider. Just three
little examples, which clearly show why it's a bad idea to use GET to
manipulate the server's state:

http://groups.google.com/group/comp.lang.php/msg/42c80631acf 96223

http://thedailywtf.com/Articles/The_Spider_of_Doom.aspx

The third one happened in my own scripts. I used to have a little form
for the users to log out. It simply showed a text like "are you sure..."
and a button to confirm. Pressing it sent a POST message to the server,
causing the user to get logged out. Worked quite well.

But then someone who uses my framework on his own sites said that this
additional confirmation step would be rather useless for his visitors
and they should be able to log out immediately by just following the
/user/logout link. OK, so I changed it, since in this case the performed
action is nothing critical. At least that was what I thought. But then
something strange happened in Firefox.

I also use automatically generated link elements in my document's heads
to indicate related documents: home, search, index, up, previous and
next document and so on. Some browsers show these links as an additional
toolbar, which I find quite useful. Firefox takes it a step further and
already downloads the next document (if there is one) in the background.
The problem was: If the user was on his own profile page /user/profile,
the next document in order was /user/logout ... The nice page preload
function turned into an auto-logout.

Micha

Re: GET or POST method?

Michael Fesser wrote:
> .oO(The Natural Philosopher)
>
>> Either method works: a GET method is slightly insecure, in that an
>> average idiots can fake a URL and maybe get where they shouldn't:
>
> If this can happen, then there's something seriously broken in the
> scripts. Even if they can get there, they shouldn't be able to do
> anything.
>
>> Its
>> harder to do with POST. There you would have to make up a web page form
>> to submit with POST to the URL you were trying to screw with.
>
> Not necessarily. There are tools that make it very easy to send
> arbitrary POST data to any script. Even the WebDeveloper toolbar in
> Firefox has some nice form functions, which allow to change the send
> method, to modify hidden or read-only fields before sending etc.
>
> And there are some more things about security to consider. Just three
> little examples, which clearly show why it's a bad idea to use GET to
> manipulate the server's state:
>
> http://groups.google.com/group/comp.lang.php/msg/42c80631acf 96223
>
> http://thedailywtf.com/Articles/The_Spider_of_Doom.aspx
>
> The third one happened in my own scripts. I used to have a little form
> for the users to log out. It simply showed a text like "are you sure..."
> and a button to confirm. Pressing it sent a POST message to the server,
> causing the user to get logged out. Worked quite well.
>
> But then someone who uses my framework on his own sites said that this
> additional confirmation step would be rather useless for his visitors
> and they should be able to log out immediately by just following the
> /user/logout link. OK, so I changed it, since in this case the performed
> action is nothing critical. At least that was what I thought. But then
> something strange happened in Firefox.
>
> I also use automatically generated link elements in my document's heads
> to indicate related documents: home, search, index, up, previous and
> next document and so on. Some browsers show these links as an additional
> toolbar, which I find quite useful. Firefox takes it a step further and
> already downloads the next document (if there is one) in the background.
> The problem was: If the user was on his own profile page /user/profile,
> the next document in order was /user/logout ... The nice page preload
> function turned into an auto-logout.
>
> Micha

Nice story Micha! and one I will bear in mind.
All I was really saying was that all a user has to do with a GET
variable, is notice what is going on in the URL window, fiddle with it,,
and maybe do strange stuff.

To do it with POST takes a *bit* more nous. Not a lot, but a bit.

You need to do data validation on both, if you care about data validity :-)