Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

POST vs GET & their intermingling.

by boo_radley (Parson)
on Dec 29, 2000 at 21:11 UTC ( #48840=perlquestion: print w/replies, xml ) Need Help??

boo_radley has asked for the wisdom of the Perl Monks concerning the following question:

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.

Replies are listed 'Best First'.
(Ovid) Re: POST vs GET & their intermingling.
by Ovid (Cardinal) on Dec 29, 2000 at 21:19 UTC
    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.

      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.
Re: POST vs GET & their intermingling.
by merlyn (Sage) on Dec 29, 2000 at 21:34 UTC
    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

      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.

      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.
        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

Re: POST vs GET & their intermingling.
by dws (Chancellor) on Dec 29, 2000 at 22:57 UTC
    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.
Re: POST vs GET & their intermingling.
by eg (Friar) on Dec 29, 2000 at 21:26 UTC

    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.

Re: POST vs GET & their intermingling.
by ctilmes (Vicar) on Jan 19, 2006 at 15:20 UTC
    GET is better for deep pages that the user might want to bookmark -- The bookmarked URL will include the right parameters.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://48840]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (4)
As of 2021-12-06 09:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    R or B?



    Results (32 votes). Check out past polls.

    Notices?