FORM data in cgi

[jponiato]

Greetings.
An HTML form submits it's data to a python cgi script on my server. This script accepts this POST data, and uses urllib.urlopen( ) to call a different cgi script (on an external server), passing this same data. I'm using cgi.FieldStorag e() to create a mapping of the FORM data, then using urllib.urlencod e() to turn it back into form data for urlopen().
Question - is there a more efficient way to do this?

I'm using an intermediary script because I want to be able to reformat the data returning from the external script before displaying it to the user.

TIA for your help.
--
Jp


"Don't let fear or good sense stop you."
-- Dennis Sollars

[Mike Meyer]

Re: FORM data in cgi

"jponiato" <jponiato@chart ermi.nojunk> writes:
[color=blue]
> Greetings.
> An HTML form submits it's data to a python cgi script on my server. This script accepts this POST data, and uses urllib.urlopen( ) to call a different cgi script (on an external server), passing this same data. I'm using cgi.FieldStorag e() to create a mapping of the FORM data, then using urllib.urlencod e() to turn it back into form data for urlopen().
> Question - is there a more efficient way to do this?[/color]

Yes. But the question you should be asking is "Is there an easier way
to do it that's worth doing?"

Unless you're passing around files, or really huge forms, the amount
of time you spend doing decoding and encodinng the form data will be
pretty trivial. Unless you're really pressed for cycles, why bother
fixing it? And if you're really pressed for cycles, you should start
by instrumenting things to make sure that you're optimizing something
that will do you some good.

Anyway, the general idea is to skip cgi.FieldStorag e, and parse the
request yourself. You'll have to deal with the headers. But you can
just grab the post data with a read(). I'm not sure you can use urllib
to send pre-encoded POST data; you'll have to check that yourself. If
not, you'll have to do the HTTP request processing by yourself. That's
not hard, though.

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Steve Holden]

Re: FORM data in cgi

Mike Meyer wrote:[color=blue]
> "jponiato" <jponiato@chart ermi.nojunk> writes:
>
>[color=green]
>>Greetings.
>>An HTML form submits it's data to a python cgi script on my server. This script accepts this POST data, and uses urllib.urlopen( ) to call a different cgi script (on an external server), passing this same data. I'm using cgi.FieldStorag e() to create a mapping of the FORM data, then using urllib.urlencod e() to turn it back into form data for urlopen().
>>Question - is there a more efficient way to do this?[/color]
>
>
> Yes. But the question you should be asking is "Is there an easier way
> to do it that's worth doing?"
>
> Unless you're passing around files, or really huge forms, the amount
> of time you spend doing decoding and encodinng the form data will be
> pretty trivial. Unless you're really pressed for cycles, why bother
> fixing it? And if you're really pressed for cycles, you should start
> by instrumenting things to make sure that you're optimizing something
> that will do you some good.
>
> Anyway, the general idea is to skip cgi.FieldStorag e, and parse the
> request yourself. You'll have to deal with the headers. But you can
> just grab the post data with a read(). I'm not sure you can use urllib
> to send pre-encoded POST data; you'll have to check that yourself. If
> not, you'll have to do the HTTP request processing by yourself. That's
> not hard, though.
>
> <mike[/color]

In point of fact the OP (whose post wasn't threaded with your reply in
my newsreader) is actually describing a requirement for an HTTP proxy!

As you describe it, since the data stream in the request body will be
exactly the same in both cases (though the HTTP request line and headers
will differ) is possible to handle the request by having the CGI script
a direct connection to the intended destination server, parsing the
incoming headers, generating the outgoing ones, and then just relaying
the request body. The response will then have to be sent back to the
client, possibly requiring some parsing on the way, so the processing
time might come out a wash.

Of course it would be even easier to set up direct proxying through the
web server if it's something accommodating like Apache ...

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/