× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Mixing GET and POST Methods
  • From: "Brad Stone" <brad@xxxxxxxxxxxx>
  • Date: Wed, 01 Aug 2001 09:34:27 -0500

My book explains how to do it too.  using APIs.  CGIDEV
isn't anything that special.  I've had the code for my
wrappers on my site (same as in my book) for a couple years
now.  (www.bvstools.com)

Also, if anyone is looking to purchase e-RPG, I might be
able to swing quite a deal on the price since I will be
buying the unsold stock from MC.  This means a "limited
amount" of low priced books.  :)  

If you're interested, mail me.  I'd like to get an idea of
how many we're looking at.

Brad
www.bvstools.com

On Mon, 30 Jul 2001 08:12:34 -0500
 Andrew.Lutz@abbott.com wrote:
> 
> 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
> +---

Bradley V. Stone
BVS.Tools
www.bvstools.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 thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.