Parsing form POST without CGI.pm on Win32

G

gnari

[ seemingly wierd problem with STDIN ]
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)

[ from another branch of this thread ]

Aaron DeLoach said:
This does not work for me (Win XP Home/Perl 5.8.4)

what about this red herring , then ?

gnari
 
A

Aaron DeLoach

Aaron DeLoach said:
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
I am updating this thread to share a solution to the original problem of
accessing the STDIN object.

It has been discussed in other newsgroups and is an IE issue. Here is a post
from microsoft.public.inetserver.iis

"The problem is that the data in STDIN is encoded in
application/x-www-form-urlencoded, not plain text. So, <STDIN> waits for a
CR/LF
which never comes. The solution is to read() $ENV{'CONTENT-LENGTH'} bytes.
To be
safe, e.g. when using multipart/form-data, binmode(STDIN) as well."

So...
{
....
binmode(STDIN);
read(STDIN, $buffer, $len) == $len
....
}

Works in IE, NN and Opera

Thanks to all that have helped!

Regards,
Aaron
 
M

Matt Garrish

Aaron DeLoach said:
I am updating this thread to share a solution to the original problem of
accessing the STDIN object.

It has been discussed in other newsgroups and is an IE issue. Here is a post
from microsoft.public.inetserver.iis

So you huffed and you puffed and you insulted regulars here just to find out
that you don't have a Perl problem? My hunch is that you wouldn't have had
this problem had you used CGI.pm. Maybe now you'll understand why it's the
recommended method, and why few here care about your problems trying to do
it on your own.

Matt
 
G

Gunnar Hjalmarsson

Matt said:
So you huffed and you puffed and you insulted regulars here just to
find out that you don't have a Perl problem? My hunch is that you
wouldn't have had this problem had you used CGI.pm. Maybe now
you'll understand why it's the recommended method, and why few here
care about your problems trying to do it on your own.

Matt, if you had read the whole thread, you'd know that a failure to
parse POSTed data with CGI.pm was the starting-point of the thread.

To Aaron:
Thanks for the update! You may have found a few replies in this thread
somewhat odd. In that case, the explanation may be that a few persons
who post here are suffering from "Matt Wright phobia". One of the
symptoms of that disease is that they have no ability to imagine that
the CGI.pm module may have any shortcoming of any kind.

As regards the solution you mentioned, binmoding STDIN (which btw was
mentioned by Brian), I had a quick glance at the CGI.pm source, and it
seems to me that the module does that by default on Windows (but I'm
far from certain). Consequently, I'm slightly confused.

Could the explanation why CGI.pm didn't work for you possibly be that
you are using an old version? I for one would find it valuable if you
could make a try with the latest CGI.pm version, and let us know if it
makes a difference.
 
A

Alan J. Flavell

Matt, if you had read the whole thread, you'd know that a failure to
parse POSTed data with CGI.pm was the starting-point of the thread.

You must be reading an entirely different posting from what I'm
seeing, then:

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

Looks good so far. It which then went on to say:

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

I don't see anything there which says "CGI.pm cannot parse submissions
on a Windows server" - do you? To me it reads like "let's optimise
prematurely". Since the poster decided to then apply the flame torch
instead of the microscalpel, I suppose we'll never really know what
was intended...

[muddle omitted for brevity]
As regards the solution you mentioned, binmoding STDIN (which btw was
mentioned by Brian), I had a quick glance at the CGI.pm source,

CGI.pm handles it just fine. What you have to grasp, I think, is that
the claim to be "using" CGI.pm in this sample code:

___
/
use CGI qw/:standard/;
$CGI::pOST_MAX=1024 * 100;
$CGI::DISABLE_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};
}
\___

was - how shall I put it? - "much exaggerated".
Could the explanation why CGI.pm didn't work for you

Please, where did it say that? The code that was presented on this
thread was hand-knitted attempts at decoding POST submissions. The
poster expressed surprise that forms submissions weren't transmitted
as plain text, for heaven's sake! Doesn't that tell you something?

ttfn
 
M

Matt Garrish

Gunnar Hjalmarsson said:
Matt, if you had read the whole thread, you'd know that a failure to
parse POSTed data with CGI.pm was the starting-point of the thread.

I don't recall his having this problem with CGI.pm:

<quote>
I use the CGI.pm module to 'paramitize' form post data. Everything works
well with this great module.
To Aaron:
Thanks for the update! You may have found a few replies in this thread
somewhat odd. In that case, the explanation may be that a few persons
who post here are suffering from "Matt Wright phobia". One of the
symptoms of that disease is that they have no ability to imagine that
the CGI.pm module may have any shortcoming of any kind.

It's hardly a new argument that CGI.pm has shortcomings. I even felt the
need to make it once upon a time myself:

http://www.perlmonks.org/index.pl?node_id=122267

The fact remains, however, that rolling one's own solution is fraught with
perils. No one has a problem with you wanting to learn or advocating
learning (or at least not me), but the majority of posters not using CGI.pm
should be. Whatever shortcomings the module has, I would still use it in a
production environment any day over a hand-rolled solution.

And as I mentioned in another post, the days of the bloat argument are fast
passing if not gone. So until someone provides me with a better reason to
parse my own parameters, I'll keep using/advocating CGI.pm.

Matt
 
G

Gunnar Hjalmarsson

Alan said:
You must be reading an entirely different posting from what I'm
seeing, then:

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

Looks good so far. It which then went on to say:

I don't see anything there which says "CGI.pm cannot parse
submissions on a Windows server" - do you?

Hmm.. Maybe I had misunderstood that. For some reason I had the
impression that the OP had failed to make the combination IE 6 + WinXP
Home + CGI.pm work as well, but now I'm in doubt. My apologies to Matt.
CGI.pm handles it just fine. What you have to grasp, I think, is
that the claim to be "using" CGI.pm in this sample code:
___
/
use CGI qw/:standard/;
$CGI::pOST_MAX=1024 * 100;
$CGI::DISABLE_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};
}
\___

was - how shall I put it? - "much exaggerated".

To me, that was not a claim to be using CGI.pm for parsing the data.
My interpretation was that the first three lines were left from
previous attempts. (The rest is part of the code I posted.)
The poster expressed surprise that forms submissions weren't
transmitted as plain text, for heaven's sake! Doesn't that tell
you something?

I saw a quote from another forum, but I read no surprise of the kind.
 
G

Gunnar Hjalmarsson

Matt said:
I don't recall his having this problem with CGI.pm:

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

Alan made me realize that I had (probably) misunderstood that. Apologies.
 
A

Alan J. Flavell

I saw a quote from another forum,

This one, isn't it? :

| It has been discussed in other newsgroups and is an IE issue. Here
| is a post from microsoft.public.inetserver.iis
|
| "The problem is that the data in STDIN is encoded in
| application/x-www-form-urlencoded, not plain text.

Quite why the submission of a form in the normal WWW-specified
encoding should be a "problem" and an "IE issue" is beyond me,
frankly. But I see no indication that CGI.pm would not have coped
with this, if only it had been given the chance.
but I read no surprise of the kind.

OK: maybe I was mistaken to interpret the uncritical regurgitation of
incompetence and confusion as "surprise".
 
C

ChrisO

gnari said:
[ seemingly wierd problem with STDIN ]

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)


[ from another branch of this thread ]

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


what about this red herring , then ?

The immediate exact question I had/have...

-ceo
 
C

ChrisO

Gunnar said:
Matt, if you had read the whole thread, you'd know that a failure to
parse POSTed data with CGI.pm was the starting-point of the thread.

To Aaron:
Thanks for the update! You may have found a few replies in this thread
somewhat odd. In that case, the explanation may be that a few persons
who post here are suffering from "Matt Wright phobia". One of the
symptoms of that disease is that they have no ability to imagine that
the CGI.pm module may have any shortcoming of any kind.

As regards the solution you mentioned, binmoding STDIN (which btw was
mentioned by Brian), I had a quick glance at the CGI.pm source, and it
seems to me that the module does that by default on Windows (but I'm
far from certain). Consequently, I'm slightly confused.

Could the explanation why CGI.pm didn't work for you possibly be that
you are using an old version? I for one would find it valuable if you
could make a try with the latest CGI.pm version, and let us know if it
makes a difference.

I'm still curious -- IE completely aside -- why...

perl -e "print while (<STDIN>)"

was reported as NOT working. This should have NOTHING to do with IE.
(Then again, under Windows, one never knows.) I understand the OP glee
that things are "working now." But I'm really curious about the other
and it were me, there's NO WAY I would be able to rest until both issues
were resolved. But that's just me...

-ceo
 
M

Michele Dondi

I am updating this thread to share a solution to the original problem of
accessing the STDIN object.
[snip]
So you huffed and you puffed and you insulted regulars here just to find out
that you don't have a Perl problem? My hunch is that you wouldn't have had
this problem had you used CGI.pm. Maybe now you'll understand why it's the
recommended method, and why few here care about your problems trying to do
it on your own.

This is not at all an excuse for having insulted helping regulars here
and without any good (or even bad!) reason, which indeed he did, but
IIRC (and I only gave a brief peek into that thread) he may have
actually had reasonably good reasons *not* to use CGI.pm. In fact
Gunnar Hjalmarsson provided non-CGI.pm solution even though he
regularly uses it per all the examples by him I've seen so far...


Michele
 
J

Joe Smith

Aaron said:
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 may have a typographical error, or an improperly installed perl.
It works for me on Win XP Home.

C:\Documents and Settings\jms>perl -e "print while (<STDIN>)"
This is the first line
This is the first line
Here comes the second
Here comes the second
^Z

C:\Documents and Settings\jms>perl -v
This is perl, v5.8.4 built for MSWin32-x86-multi-thread

-Joe
 
J

Joe Smith

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

Yes, it works just fine with Windows XP Home Version Version 2002
Service Pack 1 (build 2600).

Start -> Run -> cmd
C:\Documents and Settings\jms>perl -e "print while (<STDIN>)"
This is the first line
This is the first line
Here comes the second
Here comes the second
^Z

C:\Documents and Settings\jms>perl -v
This is perl, v5.8.4 built for MSWin32-x86-multi-thread

-Joe
 
J

Joe Smith

Aaron said:
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.

This is an example of running CGI.pm on Windows XP Home Edition.

C:\temp>type cgi-test.pl
# CGI script that creates a fill-out form
# and echoes back its values. (From 'perldoc CGI'.)

use CGI qw/-debug :standard/;
print header,
start_html('A Simple Example'),
h1('A Simple Example'),
start_form,
"What's your name? ",textfield('name'),p,
"What's the combination?", p,
checkbox_group(-name=>'words',
-values=>['eenie','meenie','minie','moe'],
-defaults=>['eenie','minie']), p,
"What's your favorite color? ",
popup_menu(-name=>'color',
-values=>['red','green','blue','chartreuse']),p,
submit,
end_form,
hr;

if (param()) {
print "Your name is",em(param('name')),p,
"The keywords are: ",em(join(", ",param('words'))),p,
"Your favorite color is ",em(param('color')),
hr;
}

C:\temp>perl cgi-test.pl
(offline mode: enter name=value pairs on standard input; press ^D or ^Z when don
e)
name=Joe
words=moe
color=blue
^Z
Content-Type: text/html; charset=ISO-8859-1

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US"><head><
title>A Simple Example</title>
</head><body><h1>A Simple Example</h1>
<form method="post" action="/cgi-test.pl"
enctype="application/x-www-form-urlencoded">
What's your name? <input type="text" name="name" value="Joe" /><p />
What's the combination?<p />
<input type="checkbox" name="words" value="eenie" />eenie
<input type="checkbox" name="words" value="meenie" />meenie
<input type="checkbox" name="words" value="minie" />minie
<input type="checkbox" name="words" value="moe" checked="checked" />moe<p />
What's your favorite color? <select name="color">
<option value="red">red</option>
<option value="green">green</option>
<option selected="selected" value="blue">blue</option>
<option value="chartreuse">chartreuse</option>
</select><p />
<input type="submit" name=".submit" />
<div><input type="hidden" name=".cgifields" value="words" /></div>
</form><hr />Your name is<em>Joe</em><p />
The keywords are: <em>moe</em><p />Your favorite color is <em>blue</em><hr />
C:\temp>
 
K

krakle

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

By that comment i'm sure we now assume you are very new indeed...
Am I the only one who rolled their eyes?
 
S

Sherm Pendley

krakle said:
Am I the only one who rolled their eyes?

No, but you're a bit late to the party - the solution was identified as
a browser bug over a week ago.

sherm--
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,766
Messages
2,569,569
Members
45,043
Latest member
CannalabsCBDReview

Latest Threads

Top