Question regarding GET and POST

[stuie...]

First off, I'm a newbie to PHP and server side scripting.

I'm curious if there are any specific guidelines as to when one should use "GET"
or "POST" in forms processing. I've had issues moreso with post than get but
have been able to resolve them relatively quickly.

Anyone?
-----------
"The day microsoft makes something that doesn't suck
is the day they start selling vacuum cleaners."

Anon. 1999

[Rob]

"stuie..." <ae******@anony mous.to> schreef in bericht
news:i1******** *************** *********@4ax.c om...

First off, I'm a newbie to PHP and server side scripting.

I'm curious if there are any specific guidelines as to when one should use "GET" or "POST" in forms processing. I've had issues moreso with post than get but have been able to resolve them relatively quickly.

Anyone?
-----------
"The day microsoft makes something that doesn't suck
is the day they start selling vacuum cleaners."

Anon. 1999

Hy stuie...,

General speaking when using GET users will see the query string in the
browser. It is also possible to change these in the browser address bar. For
instance somebody can type http://www.domain.com/delete.php?id=1 and
something where id has a value of 1 will be deleted. So the GET is less
secure.
The size of the query string in the GET method is limited (I believe it is
limited to 2000 chars, not sure about that though ) POST on the other hand
has no limits besides the one set by the providers.

Look for a more complete discussion about when to use GET or POST on

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

HTH
Rob

[John Dunlop]

F'ups to c.l.p.

Rob wrote:

[ ... ]

The size of the query string in the GET method is limited (I believe it is
limited to 2000 chars, not sure about that though )
There isn't any limit in theory. Any limit on the length of an HTTP
URI is imposed by the systems involved. RFC2616, sec. 3.2.1, says:

| The HTTP protocol does not place any a priori limit on the length of
| a URI. Servers MUST be able to handle the URI of any resource they
| serve, and SHOULD be able to handle URIs of unbounded length if they
| provide GET-based forms that could generate such URIs.

But it then goes on to warn:

| Servers ought to be cautious about depending on URI lengths
| above 255 bytes, because some older client or proxy
| implementations might not properly support these lengths.

That was in 1998 though; I believe that to be insignificant now.

RFC2616, "Hypertext Transfer Protocol -- HTTP/1.1",
http://www.ietf.org/rfc/rfc2616.txt

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

Bookmarked. Thanks, Rob. I hadn't read that before.

--
Jock

[Ashmodai]

John Dunlop scribbled something along the lines of:

F'ups to c.l.p.

Rob wrote:

[ ... ]

The size of the query string in the GET method is limited (I believe it is
limited to 2000 chars, not sure about that though )

There isn't any limit in theory. Any limit on the length of an HTTP
URI is imposed by the systems involved. RFC2616, sec. 3.2.1, says:

| The HTTP protocol does not place any a priori limit on the length of
| a URI. Servers MUST be able to handle the URI of any resource they
| serve, and SHOULD be able to handle URIs of unbounded length if they
| provide GET-based forms that could generate such URIs.

But it then goes on to warn:

| Servers ought to be cautious about depending on URI lengths
| above 255 bytes, because some older client or proxy
| implementations might not properly support these lengths.

That was in 1998 though; I believe that to be insignificant now.

May be insignigicant now, but serving content with a long string of CGI
variables attached to the script name should be avoided wherever
possible. If you submit form data which is to be processed only once
(eg. membership registration), use POST, if you only submit a short
string or so (eg. search query) or want the result page to be
bookmarkable or linkable, use GET.
If you want a GET URI that is bookmarkable but need to set myriads of
variables, better dive into techniques like those involving mod_rewrite
which will allow you to use virtual paths to transmit data, eg.
http://www.example.com/myscriptname/...wn/chimp/gwb01
instead of
http://www.example.com/myscriptname....chimp&id=gwb01

Of course you should avoid such cases in the first place by only
requiring sensible data to be transmitted and the rest to be taken from
a database or so.
--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/

[Chung Leong]

"stuie..." <ae******@anony mous.to> wrote in message
news:i1******** *************** *********@4ax.c om...

First off, I'm a newbie to PHP and server side scripting.

I'm curious if there are any specific guidelines as to when one should use "GET" or "POST" in forms processing. I've had issues moreso with post than get but have been able to resolve them relatively quickly.

A rough guideline that I follow is to use POST when the user is submitting
some data for processing/storage, and a GET when he is performing a query.
The reason for doing the latter is bookmarkability . A POST response isn't
bookmarkable/linkable.

[nospam]

In alt.php stuie... <ae******@anony mous.to> wrote:

I'm curious if there are any specific guidelines as to when one should use "GET"
or "POST" in forms processing. I've had issues moreso with post than get but
have been able to resolve them relatively quickly.

Anyone?

I myself use POST when there is a lot of data, such as TEXTAREA's or when
there is a security consideration.

Something like:

/member.php?UID= joe&PASS=secret

Is a really bad idea since UID and PASS will show up as a Referer in the
server logs or other scripts on other hosts.

Even: SessionID=1234 can be bad if the session ID happens to contain
login credentials. (In that case, it's advisable to use a cookie that
confirms the contents of session data, or (ick) use HTTP authentication
which has issues if a "Logout" feature is required.)

As others have pointed out, GET is good for queries or things you may
want the user to be able to bookmark or use their [Back] button to
access. (Say you have a POST form, user hits post, user hits [Back] some
browsers may warn that it contained POST data etc..)

I also like GET when performance is the dominant concern, since it's
already been read with the request, there is no need to read additional
data from standard input.

GET is (as far as I know) the ONLY way to get data into a script w/out
<FORM> tags, Ie, as part of a hyperlink. So, it's great for that
purpose. Also, GET is practical if you ever needed to issue a Location:
header to redirect a user to another page.

GET is generally more convenient when practical. POST is generally
better for security or when there is a lot of data.

In PHP use $REQUEST[] to use either.

Jamie

--
http://www.geniegate.com Custom web programming
User Management Solutions Perl / PHP / Java / UNIX

[Five Cats]

In message <MP************ ************@Ne ws.Individual.N ET>, John Dunlop
<us*********@jo hn.dunlop.name> writes

F'ups to c.l.p.

Rob wrote:

[ ... ]

The size of the query string in the GET method is limited (I believe it is
limited to 2000 chars, not sure about that though )
There isn't any limit in theory. Any limit on the length of an HTTP
URI is imposed by the systems involved. RFC2616, sec. 3.2.1, says:

| The HTTP protocol does not place any a priori limit on the length of
| a URI. Servers MUST be able to handle the URI of any resource they
| serve, and SHOULD be able to handle URIs of unbounded length if they
| provide GET-based forms that could generate such URIs.

But it then goes on to warn:

| Servers ought to be cautious about depending on URI lengths
| above 255 bytes, because some older client or proxy
| implementations might not properly support these lengths.

That was in 1998 though; I believe that to be insignificant now.

RFC2616, "Hypertext Transfer Protocol -- HTTP/1.1",
http://www.ietf.org/rfc/rfc2616.txt

In a more web-aware format at:

http://www.w3.org/Protocols/rfc2616/rfc2616.html
[ ... ]

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

Bookmarked. Thanks, Rob. I hadn't read that before.

--
Five Cats
Email to: cats_spam at uk2 dot net