|
midrange.com
Mel,
Instead of making everyone think that the 'only' way is with CGIDEV2 why don't
you tell them how this is done
i.e. Use the 'QtmhGetEnv' API with 'REQUEST_METHOD'. This will tell you
whether the request was GET or POST
it's really not rocket science.........
Mel Rothman
<mel@rothmanweb To: WEB400@midrange.com
.com> cc:
Sent by: Subject: Re: Mixing GET and POST
Methods
owner-web400@mi
drange.com
07/27/2001
11:06 PM
Please respond
to WEB400
Loyd, you are absolutely right about "You may either use GET *or* POST on a
single request."
However, CGIDEV2 does not "pick" which method to use. For each request, it
determines whether the request method is GET or POST (by reading the
REQUEST_METHOD environment variable) and performs the appropriate processing
(read CONTENT_LENGTH bytes from standard input if POST; retrieve QUERY_STRING
environment variable if GET). Then it makes the input data available to the
program.
It can't be known until run time which method a particular request uses. For
example, the same CGI program can be called in several ways:
1. Via a form with request method POST (or GET)
2. Via a link in another page, with or without data, in which case the browser
sends the request as a GET.
3. By the user entering a URL into the browser, again, with or without data.
You can try this yourself with virtually any CGI program written with CGIDEV2.
It is possible to have data in standard input AND in the QUERY_STRING
environment variable. I think Chris was referring to this.
For example:
<form method="post" action="/cgi-bin/programa.pgm?data=hello">
<input type="hidden" name"hide01" value="guess who?"
Other <input> tags
</form>
Standard input contains: hide01=guess+who...data from other tags...
QUERY_STRING contains: data=hello
CGIDEV2's ZhbGetInput subprocedure handles this. Unfortunately, there appears
to be a bug in the HTTP server that causes QtmhGetEnv to return QUERY_STRING
as
data=. I posted a workaround for this bug a few hours ago.
I hope this clarifies the issue for anyone interested in it.
Mel Rothman
CGIDEV2 Author
IBM Rochester
Loyd Goodbar wrote:
>
> You can mix GET and POST on the same page, but not on the same *request*.
You
> may either use GET *or* POST on a single request.
>
> You can have a single page with:
> <image>action=myprogram method=get data=hello
> <form>action=myprogram method=post data=hi
> <a href>action=myprogram method=get data=howdy
> <button>action=myprogram method=post data=heythere
>
> You cannot have a request like:
> action=myprogram method=post data=hello method=get data2=hi
>
> If you had a page with:
> method = get: value = 1
> method = post: value = 3
> cookie: value = 5
>
> Which would your RPG program choose? Would you choose the same way all the
> time? Programs (such as CGIDEV2 and PHP in *nix) that can handle these
methods
> use either the first method specified or transparently "pick one" first, and
> use it. You cannot know which that CGIDEV2 would pick without looking at the
> source. You can configure PHP to (for example) use cookies first, then post,
> then get. But you still must pick one and stick with it for that request.
>
> Please note I am saying "request", not "page".
>
> You can have a page that has distinct GET requests and POST requests to the
> same program (see above), if you're set up to handle that. But you cannot
have
> a single request that uses both.
>
> Loyd
>
> On Fri, 27 Jul 2001 15:54:14 -0400, "Christopher A. Libby"
> <clibby@mainepublicservice.com> wrote:
>
> >As a side note, I tried two tests. I first changed the form method to GET
> >and included a hidden field (func) in the form. The program worked as
> >expected. Second, with the new form I changed the method back to POST.
The
> >program again worked as expected. Can I just not mix GET and POST in the
> >same web page?
> >
> >-Chris
>
> --
> "The killer doesn't see the world like everyone else."
> "How does he see it?" "Differently." --Millennium
> lgoodbar@ispchannel.com ICQ#504581 http://lgoodbar2.pointclark.net/
> +---
+---
| This is the WEB400 Mailing List!
| To submit a new message, send your mail to WEB400@midrange.com.
| To subscribe to this list send email to WEB400-SUB@midrange.com.
| To unsubscribe from this list send email to WEB400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---
+---
| This is the WEB400 Mailing List!
| To submit a new message, send your mail to WEB400@midrange.com.
| To subscribe to this list send email to WEB400-SUB@midrange.com.
| To unsubscribe from this list send email to WEB400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
