Parsing form POST without CGI.pm on Win32

[Aaron DeLoach]

My Perl programs are developed in the Win32 environment. Some of my work
gets ported to the Unix OS.

I use the CGI.pm module to 'paramitize' form post data. Everything works
well with this great module.

However, I have a program that will be ran every ten seconds or so (maybe
more?). I use the CGI.pm just to parse the initial form post data into
parameters that I immediately place and work with in hashes (I love hashes).
We control the form post data, so I'm not terribly worried about problems
that the CGI.pm module tends too regarding such. This seems like a bit of
overkill just to parse parameters I know, but in Windows there is no STDIN
to parse form posts from like the Unix OS.

Does anybody have a work-around/solution/tip/anything to get around using
the CGI.pm for this instance?

Regards,
Aaron

 

[ChrisO]

My Perl programs are developed in the Win32 environment. Some of my work
gets ported to the Unix OS.

I use the CGI.pm module to 'paramitize' form post data. Everything works
well with this great module.

However, I have a program that will be ran every ten seconds or so (maybe
more?). I use the CGI.pm just to parse the initial form post data into
parameters that I immediately place and work with in hashes (I love hashes).
We control the form post data, so I'm not terribly worried about problems
that the CGI.pm module tends too regarding such. This seems like a bit of
overkill just to parse parameters I know, but in Windows there is no STDIN
to parse form posts from like the Unix OS.

Uh? Says who? Did you *try* any Perl scripts using STDIN? It works
just fine...? (And not just in Perl; of course there is a "standard
input.")

perl -e "print while (<STDIN>)"
Dude, this works fine!
Dude, this works fine!
^Z

Does anybody have a work-around/solution/tip/anything to get around using
the CGI.pm for this instance?

If you want to read and parse your own parameters, you can do that. I'm
not sure what "unnecessary overhead" you feel you are trying to avoid by
not using CGI.pm however. Maybe you could be more specific here. What
are you trying to avoid?

-ceo

 

[Jürgen Exner]

Aaron DeLoach wrote:
[...]

but in Windows there is no STDIN

What gave you that idea?
Of course there is.

jue

 

[Gunnar Hjalmarsson]

However, I have a program that will be ran every ten seconds or so
(maybe more?). I use the CGI.pm just to parse the initial form
post data into parameters that I immediately place and work with in
hashes (I love hashes).

This is some code I'm using for parsing CGI data in a situation where
a plain CGI script is invoked very frequently:

my (%in, $buffer);
if ($ENV{REQUEST_METHOD} eq 'POST') {
my $len = $ENV{CONTENT_LENGTH};
$len <= 131072 or die "Too much data submitted.\n";
read(STDIN, $buffer, $len) == $len
or die "Reading of posted data failed.\n";
} else {
$buffer = $ENV{QUERY_STRING};
}
$buffer =~ tr/+/ /;
for (split /[&;]/, $buffer) {
my ($name, $value) =
map { s/%(..)/chr(hex $1)/eg; $_ } split /=/, $_, 2;
$value =~ tr/\r//d; # Windows fix
$in{$name} = $value;
}

It handles submissions via query-strings as well, but if your forms
(unlike mine) have multi-value fields, the above code would require
some mods.

We control the form post data, so I'm not terribly worried about
problems that the CGI.pm module tends too regarding such.

It's good that you control the data. That's always important. What
made you believe that CGI.pm makes a difference in that respect?

... in Windows there is no STDIN to parse form posts from like the
Unix OS.

That's a misconception. What made you believe so?

 

[Aaron DeLoach]

Uh? Says who? Did you *try* any Perl scripts using STDIN? It works
just fine...? (And not just in Perl; of course there is a "standard
input.")

Did I try!! I have been trying for a few days

perl -e "print while (<STDIN>)"
Dude, this works fine!
Dude, this works fine!
^Z

This does not work for me (Win XP Home/Perl 5.8.4)

If you want to read and parse your own parameters, you can do that. I'm
not sure what "unnecessary overhead" you feel you are trying to avoid by
not using CGI.pm however. Maybe you could be more specific here. What
are you trying to avoid?

The module is just so big. It seems like loading it for my cause is
counter-productive from a performance standpoint.

 

[Aaron DeLoach]

However, I have a program that will be ran every ten seconds or so
(maybe more?). I use the CGI.pm just to parse the initial form
post data into parameters that I immediately place and work with in
hashes (I love hashes).

This is some code I'm using for parsing CGI data in a situation where
a plain CGI script is invoked very frequently:

my (%in, $buffer);
if ($ENV{REQUEST_METHOD} eq 'POST') {
my $len = $ENV{CONTENT_LENGTH};
$len <= 131072 or die "Too much data submitted.\n";
read(STDIN, $buffer, $len) == $len
or die "Reading of posted data failed.\n";
} else {
$buffer = $ENV{QUERY_STRING};
}
$buffer =~ tr/+/ /;
for (split /[&;]/, $buffer) {
my ($name, $value) =
map { s/%(..)/chr(hex $1)/eg; $_ } split /=/, $_, 2;
$value =~ tr/\r//d; # Windows fix
$in{$name} = $value;
}

It handles submissions via query-strings as well, but if your forms
(unlike mine) have multi-value fields, the above code would require
some mods.

Thank you for the algo.. but it doesn't work for me (Win XP Home/Perl
5.8.4)
What could be wrong?

 

[Gunnar Hjalmarsson]

This is some code I'm using for parsing CGI data in a situation
where a plain CGI script is invoked very frequently:

my (%in, $buffer);
if ($ENV{REQUEST_METHOD} eq 'POST') {
my $len = $ENV{CONTENT_LENGTH};
$len <= 131072 or die "Too much data submitted.\n";
read(STDIN, $buffer, $len) == $len
or die "Reading of posted data failed.\n";
} else {
$buffer = $ENV{QUERY_STRING};
}
$buffer =~ tr/+/ /;
for (split /[&;]/, $buffer) {
my ($name, $value) =
map { s/%(..)/chr(hex $1)/eg; $_ } split /=/, $_, 2;
$value =~ tr/\r//d; # Windows fix
$in{$name} = $value;
}

It handles submissions via query-strings as well, but if your
forms (unlike mine) have multi-value fields, the above code would
require some mods.

Thank you for the algo.. but it doesn't work for me (Win XP
Home/Perl 5.8.4)
What could be wrong?

Your program, perhaps? ;-)

Please post a small, complete program that does not work for you as
expected, and you'll probably get the help needed to fix it.

 

[Aaron DeLoach]

I see someone else is up late ;-)

[..]

Please post a small, complete program that does not work for you as
expected, and you'll probably get the help needed to fix it.

Easy to do! Using your code (or any other code I got from books, etc) to
deal with the STDIN all produce the same. Not an error! Just nothing.

Your code died "Reading of posted data failed." which tells me that there
must be an issue with my OS for this object.

#!/usr/bin/perl -w

use strict;
use CGI qw/:standard/;
$CGI:OST_MAX=1024 * 100;
$CGI:ISABLE_UPLOADS = 1;

my (%in, $buffer);
if ($ENV{REQUEST_METHOD} eq 'POST') {
my $len = $ENV{CONTENT_LENGTH};
$len <= 131072 or die "Too much data submitted.\n";
read(STDIN, $buffer, $len) == $len
or die "Reading of posted data failed.\n";
} else {
$buffer = $ENV{QUERY_STRING};
}
$buffer =~ tr/+/ /;
for (split /[&;]/, $buffer) {
my ($name, $value) =
map { s/%(..)/chr(hex $1)/eg; $_ } split /=/, $_, 2;
$value =~ tr/\r//d; # Windows fix
$in{$name} = $value;
}

# print the hash
print header();
while (( my $k, my $v) = each %in)
{
print "$k=>$v<br>";
}

Thanks,
Aaron

 

[Sherm Pendley]

The module is just so big. It seems like loading it for my cause is
counter-productive from a performance standpoint.

You might want to have a look at CGI::Lite on CPAN. Plain and simple
form and cookie handling, without all the HTML output cruft that CGI.pm
has accumulated over the years.

sherm--

 

[Gunnar Hjalmarsson]

Gunnar Hjalmarsson wrote:

I see someone else is up late ;-)

Not at all (this time...). It's the middle of the day here (in Sweden).

Easy to do! Using your code (or any other code I got from books,
etc) to deal with the STDIN all produce the same. Not an error!
Just nothing.

Your code died "Reading of posted data failed."

My code, unlike CGI.pm, checks the return value from read(). ;-)

which tells me that there must be an issue with my OS for this
object.

So it seems, after all. I suppose you should have a look at the
configuration of your system. STDIN simply needs to be there...

 

[Brian McCauley]

I see someone else is up late ;-)

No you don't. You see that it is not the same time of day at all
places at the same time.

Your code died "Reading of posted data failed." which tells me that there
must be an issue with my OS for this object.

#!/usr/bin/perl -w

use strict;
use CGI qw/:standard/;
$CGI:OST_MAX=1024 * 100;
$CGI:ISABLE_UPLOADS = 1;

What's the point of setting CGI's limits if you then don't use it?

my (%in, $buffer);
if ($ENV{REQUEST_METHOD} eq 'POST') {
my $len = $ENV{CONTENT_LENGTH};
$len <= 131072 or die "Too much data submitted.\n";
read(STDIN, $buffer, $len) == $len
or die "Reading of posted data failed.\n";

I think it is possible that the length doesn't match what you expected
because you didn't binmode(STDIN). Or am I imagining stuff. Does
read() honour binmode?

Still I can't see why if you are going to load CGI anyhow you don't
use it.

--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\

 

[ChrisO]

Did I try!! I have been trying for a few days




This does not work for me (Win XP Home/Perl 5.8.4)

You might want to consider reinstalling Perl then. The above Perl
one-liner should work on Win32 without any problem. It strikes me that
something isn't right somehow, if you say this does not work.

The module is just so big. It seems like loading it for my cause is
counter-productive from a performance standpoint.

I thought someone else's suggestion of CGI::Lite was a good one.

-ceo

Live deliberately.

 

[ChrisO]

This is some code I'm using for parsing CGI data in a situation
where a plain CGI script is invoked very frequently:

my (%in, $buffer);
if ($ENV{REQUEST_METHOD} eq 'POST') {
my $len = $ENV{CONTENT_LENGTH};
$len <= 131072 or die "Too much data submitted.\n";
read(STDIN, $buffer, $len) == $len
or die "Reading of posted data failed.\n";
} else {
$buffer = $ENV{QUERY_STRING};
}
$buffer =~ tr/+/ /;
for (split /[&;]/, $buffer) {
my ($name, $value) =
map { s/%(..)/chr(hex $1)/eg; $_ } split /=/, $_, 2;
$value =~ tr/\r//d; # Windows fix
$in{$name} = $value;
}

It handles submissions via query-strings as well, but if your
forms (unlike mine) have multi-value fields, the above code would
require some mods.

Thank you for the algo.. but it doesn't work for me (Win XP
Home/Perl 5.8.4)
What could be wrong?

Your program, perhaps? ;-)

Please post a small, complete program that does not work for you as
expected, and you'll probably get the help needed to fix it.

He did, in a sense, provide an example by responding that the following
does NOT work on his machine:

perl -e "print while (<STDIN>)"
When I type and hit ENTER, this will echo...
When I type and hit ENTER, this will echo...
^Z

My thought is that if *this* does not work, something is wrong with the
Perl installation likely as not. (Aside from the fact I personally
can't trust what Windows decides to do with most everything, but that's
probably beside the point.)

-ceo

Live deliberately.

 

[Aaron DeLoach]

[..]

What's the point of setting CGI's limits if you then don't use it?

We *are* using CGI.pm - we're trying to find a solution. Thye request was
for me to post some example code that dosen't work. The code I posted is
part of 300 lines.

I think it is possible that the length doesn't match what you expected
because you didn't binmode(STDIN). Or am I imagining stuff. Does
read() honour binmode?

Still I can't see why if you are going to load CGI anyhow you don't
use it.

Read the op, where I am trying to get away from this.

--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\

 

[Aaron DeLoach]

I don't think it's the Perl installation. It just so happens that I did a
full mfg re-installation a couple of days ago. It didn't work before on Perl
5.8.2, and since I had to re-install everything I upgraded Perl to 5.8.4
also. Still not working.

Is anyone getting to STDIN using Win XP *Home Version* ? I'm beginning to
believe it might not be available in the home version.

Gunnar Hjalmarsson wrote:

This is some code I'm using for parsing CGI data in a situation
where a plain CGI script is invoked very frequently:

my (%in, $buffer);
if ($ENV{REQUEST_METHOD} eq 'POST') {
my $len = $ENV{CONTENT_LENGTH};
$len <= 131072 or die "Too much data submitted.\n";
read(STDIN, $buffer, $len) == $len
or die "Reading of posted data failed.\n";
} else {
$buffer = $ENV{QUERY_STRING};
}
$buffer =~ tr/+/ /;
for (split /[&;]/, $buffer) {
my ($name, $value) =
map { s/%(..)/chr(hex $1)/eg; $_ } split /=/, $_, 2;
$value =~ tr/\r//d; # Windows fix
$in{$name} = $value;
}

It handles submissions via query-strings as well, but if your
forms (unlike mine) have multi-value fields, the above code would
require some mods.


Thank you for the algo.. but it doesn't work for me (Win XP
Home/Perl 5.8.4)
What could be wrong?

Your program, perhaps? ;-)

Please post a small, complete program that does not work for you as
expected, and you'll probably get the help needed to fix it.

He did, in a sense, provide an example by responding that the following
does NOT work on his machine:

perl -e "print while (<STDIN>)"
When I type and hit ENTER, this will echo...
When I type and hit ENTER, this will echo...
^Z

My thought is that if *this* does not work, something is wrong with the
Perl installation likely as not. (Aside from the fact I personally
can't trust what Windows decides to do with most everything, but that's
probably beside the point.)

-ceo

Live deliberately.

 

[Alan J. Flavell]

I don't think it's the Perl installation.

What's going on here? We don't have the first idea what your Perl
expertise is (ignorance of usenet netiquette is something else); all
that we can see is that you've stumbled in with some muddled code and
you can't get it to work.

It just so happens that I did a full mfg re-installation a couple of
days ago. It didn't work before on Perl 5.8.2, and since I had to
re-install everything I upgraded Perl to 5.8.4 also. Still not
working.

I'm sorry, but this is no way to get help. If you're going to use
CGI.pm then there are recipes (e.g in the online resource material
that goes with the author's book[1]). I'd recommend trying them, and
then, at least, you would have proven code, quotable symptoms which
someone might recognise, and a decent lever on whatever installation
problem you might be experiencing. Then show what you've done, what
you expected to get, show what happened - copy/paste a manageable
amount of code that you tried and the resulting diagnostics, and
you'll find any number of capable folks here who will be only too
happy to help.

Debugging hand-knitted code in an environment that you're not yet
comfortable with is like working with a hand tied behind your back.

If you're *not* going to use CGI.pm at this stage, then you're only
giving yourself additional uncertainties. I really don't recommend
it. In this kind of situation, I would seriously suggest putting the
confusion aside for the time being, going back to basics, verifying
that you can make the various elements work which contribute to your
final requirement.

Is anyone getting to STDIN using Win XP *Home Version* ?

I can't offer any practical comment on that.

I'm beginning to believe it might not be available in the home
version.

However, if that were so, I think even I would have heard about it.

Beware of Gunnar's advice - he knows what he's doing: his problem is
that he is all to ready to assume that everyone else does too. If you
have efficiency issues with CGI.pm startup, then there are better
approaches to the problem than to toss it all aside and try to knit
your own. "Don't optimise yet": get it to work first.

good luck

[1] http://www.wiley.com/legacy/compbooks/stein/source.html - but note
the date: I would recommend applying warnings and strict, and -T taint
checking too, over and above what you find in the published recipes.

 

[Aaron DeLoach]

[..]

What's going on here? We don't have the first idea what your Perl
expertise is (ignorance of usenet netiquette is something else); all
that we can see is that you've stumbled in with some muddled code and
you can't get it to work.

What didfference does it make regarding Perl experience? My problem lies
with not being able to access STDIN data on Windows XP Home edition using
Perl (or any other language for that matter). It doesn't take a genious to
write a few lines of code to print the STDIN data. I'll bet you could even
do it.

The "muddled code" was an offering by a fellow human being who had something
to offer besides words that didn't add up to anything.

It just so happens that I did a full mfg re-installation a couple of
days ago. It didn't work before on Perl 5.8.2, and since I had to
re-install everything I upgraded Perl to 5.8.4 also. Still not
working.

I'm sorry, but this is no way to get help. If you're going to use
CGI.pm then there are recipes (e.g in the online resource material
that goes with the author's book[1]). I'd recommend trying them, and
then, at least, you would have proven code, quotable symptoms which
someone might recognise, and a decent lever on whatever installation
problem you might be experiencing. Then show what you've done, what
you expected to get, show what happened - copy/paste a manageable
amount of code that you tried and the resulting diagnostics, and
you'll find any number of capable folks here who will be only too
happy to help.

Your lack of knowledge (or effort to read) of the op and subsequent
discussions *really* shows here. You should have just stopped here, but you
continue to show yourself...

Debugging hand-knitted code in an environment that you're not yet
comfortable with is like working with a hand tied behind your back.

If you're *not* going to use CGI.pm at this stage, then you're only
giving yourself additional uncertainties. I really don't recommend
it. In this kind of situation, I would seriously suggest putting the
confusion aside for the time being, going back to basics, verifying
that you can make the various elements work which contribute to your
final requirement.

There's no confusion at all except on your part. This thread is actually
leading me to a viable solution. The last time I checked, that was what the
ng was for.

I can't offer any practical comment on that.


However, if that were so, I think even I would have heard about it.

You should have said "...even *I* whould have heard about it"

Beware of Gunnar's advice - he knows what he's doing: his problem is
that he is all to ready to assume that everyone else does too. If you
have efficiency issues with CGI.pm startup, then there are better
approaches to the problem than to toss it all aside and try to knit
your own. "Don't optimise yet": get it to work first.

It's been working for a long time now. I'm in the process of fine tuning
some code, that's all. If you would have read the op you would have been
aware that nothing was broken in the code to begin with.

Against my better judgement, let me get ignorant now...

You start off by insulting someone you know nothing about. You insuate
"ignorance" based on your perception of yourself. That, my friend, is
ignorant.

You should be more careful. I just might be the owner of several dozen
fortune 500 companies who likes to get dirty himself. In fact, *I* might be
the one writing *your* paycheck. But that doesn't make me better than you.
Nor does it put me on a level looking down on you. Be careful who you call
ignorant next time.

I know I shouldn't have said these things, but you pissed me off. I'll
regret having posted this later.

good luck

**** off!

 

[Aaron DeLoach]

My Perl programs are developed in the Win32 environment. Some of my work
gets ported to the Unix OS.

I use the CGI.pm module to 'paramitize' form post data. Everything works
well with this great module.

However, I have a program that will be ran every ten seconds or so (maybe
more?). I use the CGI.pm just to parse the initial form post data into
parameters that I immediately place and work with in hashes (I love hashes).
We control the form post data, so I'm not terribly worried about problems
that the CGI.pm module tends too regarding such. This seems like a bit of
overkill just to parse parameters I know, but in Windows there is no STDIN
to parse form posts from like the Unix OS.

Does anybody have a work-around/solution/tip/anything to get around using
the CGI.pm for this instance?

Regards,
Aaron

I am posting this message to update the thread. Maybe it will help someone
else.

Throughout my trials with this subject I was lead to believe that WinXP Home
did not expose the STDIN object. The problem is an Internet Explorer 6 issue
(I don't know about earlier versions) . I could not read the STDIN via Perl
when a form was submitted with IE 6. On NN and Opera the STDIN was
available. Now I'll try to find the solution... (I'll update the ng)

Regards,
Aaron

 

[Sam Holden]

I know I shouldn't have said these things, but you pissed me off. I'll
regret having posted this later.

Yes you will, assuming you ever have another question for this newsgroup
that you actually want the maximum number of experienced perl coders,
trainers, and generally helpful types to see.

 

[Michele Dondi]

I can't offer any practical comment on that.

Me neither...

....but! I really can't believe it can be so. For one thing tons of
programs would not work, and this is a good reason, period. Also, why
shouldn't here been something that's been in *all* M$ OSen I know of?

Now that I think of it, I fear that the OP may have misunderstood what
Gunnar correctly suggested to him as a test and now, to be sure, I'm
referring directly to him: (i) open a terminal window (cmd.exe), (ii)
type

perl -e "print while <STDIN>"

at the prompt. Then type what you like, e.g. some words and press
return. You should get something like

C:\WINDOWS>perl -e "print while <STDIN>"
foo
foo
bar
bar

here the first "foo" and "bar" respectively are what you typed
literally, echoed to the terminal. The second ones are those output by
the script. To terminate press ^Z (eof in DOS/Win*).


HTH,
Michele