GET vs POST

[Christopher Benson-Manica]

I'm still quite unclear as to what exactly the difference between METHOD=GET
and METHOD=POST is for forms, even after looking in several books an on the
web. I'd appreciate any clarifications you could give me.

I'm in a situation where I'd like to pass the elements of a Javascript date
separately (year, month, date, hour, minute, second) to a CGI. If I were to
store these values in a hidden form and at some point submit that form, would
I want the method for that form to be GET or POST?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Fred Serry]

"Christopher Benson-Manica" schreef...

I'm still quite unclear as to what exactly the difference between METHOD=GET and METHOD=POST is for forms, even after looking in several books an on the web. I'd appreciate any clarifications you could give me.

I'm in a situation where I'd like to pass the elements of a Javascript date separately (year, month, date, hour, minute, second) to a CGI. If I were to store these values in a hidden form and at some point submit that form, would I want the method for that form to be GET or POST?

Hi,

This may be a good starting point:

http://www.w3.org/TR/html4/interact/...#submit-format

Some practical things:

A GET can be bookmarked, while a POST can usually not.
Form data from a GET is easely recovered from history, thus not usable for
things like passwords.

Fred

[David Dorward]

Christopher Benson-Manica wrote:

I'm still quite unclear as to what exactly the difference between
METHOD=GET and METHOD=POST is for forms, even after looking in several
books an on the web. I'd appreciate any clarifications you could give me.
Get encodes the data in the query string section of the URI and is for
queries which don't make any change on the server. As the data is in the
URI, it is bookmarkable.

Post encodes the data as seperate http headers, and is for queries which do
make changes on the server. Post also allows much more data to be sent.
I'm in a situation where I'd like to pass the elements of a Javascript
date separately (year, month, date, hour, minute, second) to a CGI. If I
were to store these values in a hidden form and at some point submit that
form, would I want the method for that form to be GET or POST?

That depends what you want to do with it.

--
David Dorward http://dorward.me.uk/

[Mike]

The main difference that matters most, to us as developers, is the placing
of all the "stuff" sent along when you "submit" a form.

Suppose you have a <input type="input" name="junk"> on your form.
When the form is submitted, the URL specified on the <form ACTION="URL"> is
called.
This URL will receive a parameter name/value pair of "junk=(contents of the
input box)"

If the <form> specified a METHOD of GET, <form ACTION="URL" METHOD="GET">,
the URL will be called
as the following
"URL?junk=(contents of the input box)"

If the <form> specified a METHOD of POST, <form ACTION="URL" METHOD="POST">,
the URL will be called
as the following
"URL"
Note, there is no "?junk=(contents of input box)" text string trailing the
URL.

The receiving URL will still have access to the "junk=(contents of input
box)" name/value pair, but it does not show up in the browsers URL location
box.

The name/value pair of "junk=(contents of input box)" is in the HTTP headers
(I think). In either case the following ASP code will retreive the
name/value pair...
Request("junk")

The statement Request("junk") will return the string that is the contents of
the text box when the form was submit'ted

"Christopher Benson-Manica" <at***@nospam.cyberspace.org> wrote in message
news:bo**********@chessie.cirr.com...

I'm still quite unclear as to what exactly the difference between METHOD=GET and METHOD=POST is for forms, even after looking in several books an on the web. I'd appreciate any clarifications you could give me.

I'm in a situation where I'd like to pass the elements of a Javascript date separately (year, month, date, hour, minute, second) to a CGI. If I were to store these values in a hidden form and at some point submit that form, would I want the method for that form to be GET or POST?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[kaeli]

In article <bo**********@chessie.cirr.com>, at***@nospam.cyberspace.org
enlightened us with...

I'm still quite unclear as to what exactly the difference between METHOD=GET
and METHOD=POST is for forms, even after looking in several books an on the
web. I'd appreciate any clarifications you could give me.

http://ist-socrates.berkeley.edu:730...ec/page17.html
I'm in a situation where I'd like to pass the elements of a Javascript date
separately (year, month, date, hour, minute, second) to a CGI. If I were to
store these values in a hidden form and at some point submit that form, would
I want the method for that form to be GET or POST?

Depends on your needs. See link above.

-------------------------------------------------
~kaeli~
Jesus saves, Allah protects, and Cthulhu
thinks you'd make a nice sandwich.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace
-------------------------------------------------

[Jim Dabell]

Christopher Benson-Manica wrote:

I'm still quite unclear as to what exactly the difference between
METHOD=GET and METHOD=POST is for forms, even after looking in several
books an on the web. I'd appreciate any clarifications you could give me.
GET retrieves a resource from a server. POST sends information to a server,
and (usually) gets a resource in response.

I'm in a situation where I'd like to pass the elements of a Javascript
date separately (year, month, date, hour, minute, second) to a CGI. If I
were to store these values in a hidden form and at some point submit that
form, would I want the method for that form to be GET or POST?

It depends why you are doing it. If the form handler is supposed to take
that information and store it in a database or something, then use POST.
If you are retrieving time-sensitive information, use GET. If the amount
of information is 'large', then use POST as well, since you can't rely on
extremely long URLs to be handled correctly.

The HTTP 1.1 specification, RFC 2616 goes into more detail:

<URL:http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9>
--
Jim Dabell

[r a n d e l l d]

"Christopher Benson-Manica" <at***@nospam.cyberspace.org> wrote in message
news:bo**********@chessie.cirr.com...

I'm still quite unclear as to what exactly the difference between METHOD=GET and METHOD=POST is for forms, even after looking in several books an on the web. I'd appreciate any clarifications you could give me.

I'm in a situation where I'd like to pass the elements of a Javascript date separately (year, month, date, hour, minute, second) to a CGI. If I were to store these values in a hidden form and at some point submit that form, would I want the method for that form to be GET or POST?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

Besides whatevery one else has mentioned - I believe GET is confined to 1024
characters while POST has no such limits.. though limits on client memory,
connection speed and client/server timeouts might effect a really long
POST...

[Mikhail Esteves]

r a n d e l l d, on Thu, 06 Nov 2003 05:20:15 +0000, had to say:

Besides whatevery one else has mentioned - I believe GET is confined to
1024 characters while POST has no such limits.. though limits on client
memory, connection speed and client/server timeouts might effect a
really long POST...

GET is confined to 256 characters.

From w3.org:
(http://www.w3.org/2001/tag/doc/whenT...-20030509.html)

5.2 Ephemeral limitations

While Web application design must take into account the limitations of
technology that is widely deployed at present, it should not treat these
as architectural invariants. The following is a list of limitations have
already been largely resolved, or are likely to fade away as bugs are
fixed and the scope of interoperable specifications expands.

URIs cannot be longer than 256 characters
This was a limitation in some server implementations, and while
servers continue to have limitations to prevent denial-of-service
attacks, they are generally at least 4000 characters, and they evolve
as the legitimate uses of application developers evolve.
GET requests are re-executed when the user uses the back button.
This is not by design. Section 13.13 of [RFC2396] states: "History
mechanisms and caches are different. In particular history mechanisms
SHOULD NOT try to show a semantically transparent view of the current
state of a resource. Rather, a history mechanism is meant to show
exactly what the user saw at the time when the resource was
retrieved."
If I visit a page via a secure protocol, and then follow a link to another
page, the second site may have access to sensitive data in a URI.
This is not by design. Section 15.1.3 of [RFC2396] states: "Because
the source of a link might be private information or might reveal an
otherwise private information source, it is strongly recommended that
the user be able to select whether or not the "Referer" [sic] field is
sent. For example, a browser client could have a toggle switch for
browsing openly/anonymously, which would respectively enable/disable
the sending of Referer and From information. Clients SHOULD NOT
include a Referer header field in a (non-secure) HTTP request if the
referring page was transferred with a secure protocol."
Search services will not index anything with a "?" in the URI.
This was a heuristic to avoid infinite loops in some search service
crawlers, but it was not an architectural constraint, and modern
search services use more sophisticated heuristics to avoid loops.

[keyur shah]

Get -- limits amount of data u can send over wire from one page to
another.

Not secured.... as data goes as query string...

Post --- no limit on amount of data to be sent over wire...

secured way of sending data... in form of form elements...

Keyur Shah
Verizon Communications
732-423-0745

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Stephen]

Mikhail Esteves wrote:

r a n d e l l d, on Thu, 06 Nov 2003 05:20:15 +0000, had to say:

Besides whatevery one else has mentioned - I believe GET is confined to
1024 characters while POST has no such limits.. though limits on client
memory, connection speed and client/server timeouts might effect a
really long POST...

GET is confined to 256 characters.

No, you're not correctly reading the material you quoted. As pointed out
in previous posts, the GET data is transmitted in the request URI. The
RFCs do not specify a limit; this is implementation-specific.

What the quoted paragraph below states is: Some older server
implementations may have placed a 256-char limit, but generall NO LONGER
DO. (Shoot, a HOSTNAME can be up to 255 chars, so it doesn't make much
sense to limit an entire URI to 256.)

Some servers do implement limits on both URI size and request-body size
in order to thwart DOS attacks employing huge URIs or request-bodies.
URI limitations at the client side are likely to be OS or browser
properties. For example in Windows, the limit is 2083 characters (e.g.
as defined in commctrl.h or wininet.h -- see the MS platform SDK).

The maximum amount of GET data that can be transmitted in the URI will
be the OS/browser limitation on total URI size minus the total of the
length of the scheme + 3( the "://" ) + hostname + urlpath + 1 for the
"?" delimiting the query string. If there's any room left over, that's
how much room you have for your GET data. This is independent of what
any particular server may accept.
From w3.org:
(http://www.w3.org/2001/tag/doc/whenT...-20030509.html)

5.2 Ephemeral limitations

[...snip...] The following is *a list of limitations have [sic]
already been largely resolved* [emphasis added], or are likely to fade away as bugs are
fixed and the scope of interoperable specifications expands.

URIs cannot be longer than 256 characters
This *was* a limitation in some *server implementations* [emphasis added], and while
servers continue to have limitations to prevent denial-of-service
attacks, they are generally at least 4000 characters, and they evolve
as the legitimate uses of application developers evolve.
[...snip...}

Regards,
Stephen

[Stephen]

Mike wrote:

The main difference that matters most, to us as developers, is the placing
of all the "stuff" sent along when you "submit" a form.

Suppose you have a <input type="input" name="junk"> on your form.
When the form is submitted, the URL specified on the <form ACTION="URL"> is
called.
Picky, perhaps, but more correct to say that the resource identified by
the URL is "requested", whether GET or POST (or any other method) is used.
[...snip...]
[For POST,]
The name/value pair of "junk=(contents of input box)" is in the HTTP headers
(I think).

Using request method POST, the name=value pairs are contained in the
body of the request.

Request line: POST /some/file.asp HTTP/1.1
Headers: Host: http://example.com
<may be more headers>
Blank line: <extra CRLF pair separates headers from body>
Body of request: <name=value pairs go here>
Regards,
Stephen