POST vs GET & their intermingling.

[boo_radley]

While working on a CGI project, it's been suggested that we submit some information via GET method, and other information via POST, e.g. have the web page submit username & sundry data through POST, but still rely on GET to determine the flow of the script like : http://www.bogusurl.com/gne.cgi&action=go. This seems like a bad idea, since the FORM element accepts only one or the other, but not both. I'd appreciate any thoughts or experiences.

[Ovid]

GET and POST are not interchangeable and shouldn't be used as such. Proxy servers may cache the output of GET requests, browsers should prompt you if you hit refresh on a POST, and the two types are different. In practice, the only distinction that most notice is that POST requests are not logged, but GET requests are (since the query string is in the headers).

If you are using CGI.pm and need to use a POST but still have a query string embedded in the URL, open CGI.pm and look for the following:

      # Some people want to have their cake and eat it too!
      # Uncomment this line to have the contents of the query string
      # APPENDED to the POST data.
      # $query_string .= (length($query_string) ? '&' : '') . $ENV{'QU
+ERY_STRING'} if defined $ENV{'QUERY_STRING'};

As a general rule of thumb, use GET when you *get* information from a server without changing it. Use POST when you *post* information to a server and thus change it. That's why we have two methods.

If you must mix and match methods, make sure that you don't use GET when you alter data on the server! Since browsers generally do not prompt on reload for a GET request, a user could inadvertently refresh a page and post data multiple times. Some browsers still allow this for a POST, but it's less common.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[Fastolfe]

In addition, some (goofy) proxy servers periodically re-fetch pages retrieved via GET to keep their cache up to date I guess. As Ovid says, GET should be used when you're just fetching information, and it doesn't matter how many times that data is fetched. POST should be used whenever you want to activate an action or change data, anything that should only be done once and with the explicit activation by a browser.

[merlyn]

perldoc CGI reveals:

  MIXING POST AND URL PARAMETERS

       $color = $query->url_param('color');

    It is possible for a script to receive CGI parameters in the URL a
+s well
    as in the fill-out form by creating a form that POSTs to a URL
    containing a query string (a "?" mark followed by arguments). The
    param() method will always return the contents of the POSTed fill-
+out
    form, ignoring the URL's query string. To retrieve URL parameters,
+ call
    the url_param() method. Use it in the same way as param(). The mai
+n
    difference is that it allows you to read the parameters, but not s
+et
    them.

    Under no circumstances will the contents of the URL query string
    interfere with similarly-named CGI parameters in POSTed forms. If 
+you
    try to mix a URL query string with a form submitted with the GET m
+ethod,
    the results will not be what you expect.

-- Randal L. Schwartz, Perl hacker

[Dominus]

Says merlyn, quoting Lincoln Stein:

Under no circumstances will the contents of the URL query string interfere with similarly-named CGI parameters in POSTed forms.

That's a nice theory, but if the browser screws it up, there is nothing that Lincoln or CGI.pm can do to unscrew it. And in my experience, this is one of the cases that browsers are most likely to screw up.

Many browsers like to take the URL parameters and the posted form data and mingle them in various nasty ways.

[boo_radley]

Under no circumstances will the contents of the URL query string interfere with similarly-named CGI parameters in POSTed forms. If you try to mix a URL query string with a form submitted with the GET method, the results will not be what you expect.

I came to this same conclusion after reading the specification for the FORM tag.

[merlyn]

I came to this same conclusion after reading the specification for the FORM tag.

Hmm. I just skimmed through that specification, and couldn't see how you came to that conclusion.

There seems to be three uncorrelated elements:

1. Whether the form parameters to be sent can come from both the action attribute and the form elements themselves (unclear in the spec)
2. Whether those parmeters are encoded using GET or POST methods (selected by the form's method attribute)
3. Whether the CGI processing agent should interpret query-string parameters in addition to content parameters when using the POST method (not specified at all in that referenced spec - that would be in a CGI spec)
Did you read something I didn't?

-- Randal L. Schwartz, Perl hacker

[dws]

Another pitfall that awaits those who use GET is that there are poorly-documented, inconsistently enforced limits to the size of a URL. (If you have pointers to documented limits, please reply.) My rule of thumb (aside from using GET to get information and POST to send), is to never let a URL get longer than 128 characters. That may be overly conservative, but it hasn't gotten me into trouble.

[eg]

I was on a job that had this. The (front-end) site was just one big ol' CGI application that had $ENV{QUERY_STRING} parsed up at the very top before the request was handed off to other perl modules. It wasn't so bad -- sort of elegant, actually -- it just stuffed everything into $cgi->param( $key => $value ); pairs so it was essentially transparent to the developers.

Still, with careful desgin, it probably isn't necessary. But if you need (or want) to do it, I certainly wouldn't avoid it.

[ctilmes]

GET is better for deep pages that the user might want to bookmark -- The bookmarked URL will include the right parameters.