arrange form data in same order as on form

[bbxrider]

is there a way to sort (or other method) the 'method=post' data fields from
a form into
the same order they appear in the form
when i use the following code there doesn't appear to be any particular
order to how they are arranged

read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
foreach $pair (@pairs) {
($name, $value) = split(/=/, $pair);
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$FORM{$name} = $value;

 

[Ben Morrow]

is there a way to sort (or other method) the 'method=post' data fields from
a form into
the same order they appear in the form
when i use the following code there doesn't appear to be any particular
order to how they are arranged

read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
foreach $pair (@pairs) {
($name, $value) = split(/=/, $pair);
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$FORM{$name} = $value;

Firstly, you *really* should be using CGI or CGI::Lite rather than
parsing stdin yourself.

If the browser doesn't return them in order, then the only way to put
them back in order is to know what order they were in on the original
form. One way of doing this might be to give them names beginning with
'01', '02' etc.: if you generate the form yourself you can automate
this.

Note that hashes are inherently unordered: if you create a hash with
more than one key there is *no* guarantee about the order you will get
the keys back in when you list them. If you need there to be, then
either keep a separate array of keys to hold the order, or use
Tie::IxHash from CPAN which does that for you.

Ben

 

[A. Sinan Unur]

is there a way to sort (or other method) the 'method=post' data
fields from a form into the same order they appear in the form
when i use the following code there doesn't appear to be any
particular order to how they are arranged

why do you care?

read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);

this code is buggy. either write your own, taking into account all the fine
points of the specs, or just use CGI.pm. but don't use someone else's buggy
code.

Sinan.

 

[Eric J. Roode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

is there a way to sort (or other method) the 'method=post' data
fields from a form into
the same order they appear in the form
when i use the following code there doesn't appear to be any
particular order to how they are arranged

The CGI spec does not guarantee that the form variables will be submitted
in any particular order, so you're out of luck.

read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
foreach $pair (@pairs) {
($name, $value) = split(/=/, $pair);
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$FORM{$name} = $value;

This is exceedingly bad code. Unless you really know what you're doing,
and have strong reasons not to, you should use the CGI module.

We keep seeing this exact same bad code posted to this newsgroup. Out of
curiosity, where did you copy it from?

- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBP7Qbf2PeouIeTNHoEQKb6gCfbgrhGAcLpyRLTC5cUW4U1AsVIsQAn3Ev
bAiVGyJb/3J4v/fhU4Yi9w1q
=vDoO
-----END PGP SIGNATURE-----

 

[Gunnar Hjalmarsson]

this code is buggy.

Do you know the context in which that code is used? If not, you can't
reasonably tell whether it's "buggy".

either write your own, taking into account all the fine
points of the specs,

That's important only if you are writing a general purpose function or
module. What makes you think that that is what OP is about to do?

or just use CGI.pm.

That is one option.

 

[Ben Morrow]

Do you know the context in which that code is used? If not, you can't
reasonably tell whether it's "buggy".

The OP is attempting to interpret a CGI POST request, as stated in the
Original Post.

That's important only if you are writing a general purpose function or
module. What makes you think that that is what OP is about to do?

It is important in all circumstances where the data being received is
not entirely under your control; eminently the case in a CGI
environment.

That is one option.

....and by far the best[1], unless you are (a) very clever and (b) need to
do something particular that CGI.pm doesn't do for you.

The whole *point* of CPAN is so that people don't have to keep failing
to solve the same difficult problems over and over again.

Ben

[1] modulo equivalent alternatives, such as CGI::Lite.

 

[Gunnar Hjalmarsson]

The OP is attempting to interpret a CGI POST request, as stated in
the Original Post.

I meant context in a more narrow sense, of course.

Still don't understand what it is that makes the above code "buggy".

It is important in all circumstances where the data being received
is not entirely under your control; eminently the case in a CGI
environment.

What's important in those circumstances is that you validate the data
properly, run the program in taint mode, etc. Using CGI.pm does not
take care of everything, right?

That is one option.

...and by far the best[1], unless you are (a) very clever and (b)
need to do something particular that CGI.pm doesn't do for you.

The whole *point* of CPAN is so that people don't have to keep
failing to solve the same difficult problems over and over again.

I'm not questioning the advantages with code reuse in general. I'm
just (once again) reacting to the aggressive way, sometimes not to the
point, in which some people here argue for using CGI.pm.

 

[Eric Schwartz]

Still don't understand what it is that makes the above code "buggy".

The read() may not read $ENV{'CONTENT_LENGTH'} bytes into $buffer, and
there's no attempt made to detect or handle this event. Without going
to the effort of reading the original post I don't know for sure, but
I'd bet there's at least three or four other instances where CGI.pm
handles things correctly that the OP's code does not.

What's important in those circumstances is that you validate the data
properly, run the program in taint mode, etc. Using CGI.pm does not
take care of everything, right?

No, but it removes one axis of variability from the list of things
that could be buggy. Given the option of using known-good code and
hacking something up yourself, why (other than learning excercises,
which are surely valuable) would you not use the tested and verified
code?

-=Eric

 

[Gunnar Hjalmarsson]

The read() may not read $ENV{'CONTENT_LENGTH'} bytes into $buffer,
and there's no attempt made to detect or handle this event.

Some kind of exception handling is most often useful, but the lack of
it isn't exactly a _bug_, is it?

Without going to the effort of reading the original post I don't
know for sure, but I'd bet there's at least three or four other
instances where CGI.pm handles things correctly that the OP's code
does not.

None of us knows which of those "things" that are _applicable_ in OP's
program.

No, but it removes one axis of variability from the list of things
that could be buggy. Given the option of using known-good code and
hacking something up yourself, why (other than learning
excercises, which are surely valuable) would you not use the tested
and verified code?

I very much dislike the aggressive way in which some people here
advocate the use of CGI, and the lack of faith that is shown in
people's own judge. The described attitude makes me suspicious and
less inclined to listen. How about that for a reason?

 

[Eric Schwartz]

Some kind of exception handling is most often useful, but the lack of
it isn't exactly a _bug_, is it?

Is this buggy?

open(FH, '>', "/root/file");
print FH @data;

I'd say heck yeah, because there's no checking that FH was properly
opened, and that's the exact same class of bug we're talking about in
the OP.

None of us knows which of those "things" that are _applicable_ in OP's
program.

Does it matter? As long as there are any, it means that using CGI.pm
(or some equivalent, such as CGI::Lite, or what-have-you) is a better
solution than rolling it on your own. Again, I make exceptions for
doing it for personal learning purposes, because it's good to learn
how to do things, but it's just nuts to not use a module in a
production environment.

I very much dislike the aggressive way in which some people here
advocate the use of CGI, and the lack of faith that is shown in
people's own judge. The described attitude makes me suspicious and
less inclined to listen. How about that for a reason?

I know you're being snarky, but I'll answer it honestly: it sucks as a
reason. It's juvenile and immature, and overlooks the real benefits
in favour of rebellion for its own sake. It's not that I have a lack
of faith in people's judgement, it's that I have never-- not *once*--
seen hand-rolled CGI parsing code on this newsgroup that wasn't buggy.

Most of the arguments against using CGI.pm, including "it's too slow",
aren't based on facts, they're based on suppositions, and "well, it
stands to reason". Sometimes they're based on facts, and then people
usually agree that that's a bad case to use it in, but I'd
conservatively estimate that 98% of the time it's the way to go.

I'll grant you, there are times when it's a good idea to roll your own
CGI parsing routines. Personal study is one. I can't think of any
situation for which I'd want to CGI.pm that it doesn't already work
for, but if there is one, that's a good reason-- though a better idea,
IMO, is to fix CGI.pm and thus make everyone's life that much better.
Sometimes you don't need the HTML generation routines, and in that
case there are modules like CGI::Lite and others that do the parsing
job for you.

In the end, there are a gazillion ways to get it wrong, and only a
very few ways to do it right. And people being people, the sort of
person who thinks they're saving time and effort by not using CGI.pm
(or equivalent) is not as a rule the sort of person that's going to
take the very painstaking approach of reading the RFCs and following
them correctly, leading to the

10 Hey, it works for me.
20 <tweak>
30 Oh, crap, now it's broke. <code>
40 GOTO 10

loop we're all so painfully familiar with.

-=Eric

 

[A. Sinan Unur]

Some kind of exception handling is most often useful, but the lack of
it isn't exactly a _bug_, is it?

OK, you can call it something else then. Let's assume you don't care about
that. There is still the fact that

will miss pairs separated by a semicolon. In addition, parameter names are
not unescaped. What happens when the query string given is

?param=;

I very much dislike the aggressive way in which some people here
advocate the use of CGI, and the lack of faith that is shown in
people's own judge.

As Eric Roode pointed out, the same exact code has been posted here
numerous times (e.g. http://groups.google.com/groups?hl=en&lr=&ie=UTF-8
&oe=UTF-8&safe=off&selm=4096148f.0310161157.9400327%40posting.google.com)
so I assumed the OP was not relying on his own judgement, but using someone
else's code. In that case, he is better off using CGI.pm.

Sinan.

 

[A. Sinan Unur]

read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
foreach $pair (@pairs) {
($name, $value) = split(/=/, $pair);
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$FORM{$name} = $value;

....
We keep seeing this exact same bad code posted to this newsgroup. Out
of curiosity, where did you copy it from?

It seems to date back to 1996 or even earlier:

http://tinyurl.com/uxq2

 

[bbxrider]

thanks for all the help and opinions
i'm just self learning perl and found some code at
http://www.cgi101.com/class/
and some other searching google groups
actually i dont even know what cgi.pm and cgi lite are but will surely find
out
i dont' mean to try and just steal code, but have found that seeing, using
and understanding examples
really accelerates my learing curve
what i've since found is that the variable containing the form input is in
fact in the same order as the form
this code keeps the original order
foreach (split(/[&;]/, $buffer)) {
s/\+/ /g ;
($name, $value)= split('=', $_, 2) ;
$name=~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/ge ;
$value=~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/ge ;
print "$name = $value";
$buffer{$name}.= "\0" if defined($in{$name}) ; # concatenate
multiple vars
$buffer{$name}.= $value ;
}
i have already set up sql query based inserts that expect the data fields in
order and since there are 67
on the form i want to be able to reuse that code
again thanks for the help, this is a great forum and would hope to return
the help someday

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

is there a way to sort (or other method) the 'method=post' data
fields from a form into
the same order they appear in the form
when i use the following code there doesn't appear to be any
particular order to how they are arranged

The CGI spec does not guarantee that the form variables will be submitted
in any particular order, so you're out of luck.

read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
foreach $pair (@pairs) {
($name, $value) = split(/=/, $pair);
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$FORM{$name} = $value;

This is exceedingly bad code. Unless you really know what you're doing,
and have strong reasons not to, you should use the CGI module.

We keep seeing this exact same bad code posted to this newsgroup. Out of
curiosity, where did you copy it from?

- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBP7Qbf2PeouIeTNHoEQKb6gCfbgrhGAcLpyRLTC5cUW4U1AsVIsQAn3Ev
bAiVGyJb/3J4v/fhU4Yi9w1q
=vDoO
-----END PGP SIGNATURE-----

 

[Gunnar Hjalmarsson]

There is still the fact that


will miss pairs separated by a semicolon.

Not applicable. Look at OP's original post again. Parameters submitted
via forms using the POST method are not separated by semicolons.

In addition, parameter names are
not unescaped. What happens when the query string given is

?param=;

Nothing, since the code does not parse query strings.

I know that you know better than that, Sinan. But now we are talking
about the 'sacred cow' CGI.pm, so the usually educated, logical posts
from you are suddenly replaced with incorrect or questionable
statements. It's anything but convincing.

 

[Gunnar Hjalmarsson]

I know you're being snarky, but I'll answer it honestly: it sucks
as a reason. It's juvenile and immature, and overlooks the real
benefits in favour of rebellion for its own sake.

Maybe true, when you look at it from a rational angle. But it's human.

See my latest reply to Sinan. (This is my last post in this thread, I
promise. )

 

[Ben Morrow]

[please don't top-post]

thanks for all the help and opinions i'm just self learning perl and
found some code at http://www.cgi101.com/class/ and some other
searching google groups actually i dont even know what cgi.pm and
cgi lite are but will surely find out

For CGI, type 'perldoc CGI' at a command prompt. CGI::Lite you would
need to install. Note that the names of Perl modules are case-sensitive.

i dont' mean to try and just steal code, but have found that seeing,
using and understanding examples really accelerates my learing curve

Absolutely. Reading decent code is one of the best ways to learn. You
do have to be sure your source is reliable, though: there is one hell
of a lot of very bad Perl floating around the web.

what i've since found is that the variable containing the form input
is in fact in the same order as the form this code keeps the
original order

I don't think this is guaranteed, by which I mean that it may happen
to work for you with your browser during this phase of the moon, but
under other circumstances it may well not. If you need to keep
separate track of the different paramaters, give them different
names. Change whatever generates them to put a number on the end, or
something.

Ben

 

[A. Sinan Unur]

Nothing, since the code does not parse query strings.

Hmmmm ... Let's say I have been doing too much 'task-switching' today,
leading to muddled thinking.

But now we are talking about the 'sacred cow' CGI.pm, so the
usually educated, logical posts from you are suddenly replaced with
incorrect or questionable statements.

It is not that ... Simply jumbled neural paths or something. I do
apologize.

Sinan.

 

[Keith Keller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Not applicable. Look at OP's original post again. Parameters submitted
via forms using the POST method are not separated by semicolons.

What if he wants to support GET in the future?

Nothing, since the code does not parse query strings.

What if he wants to parse query strings in the future?

- --keith

- --
(e-mail address removed)-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/tFDihVcNCxZ5ID8RApBfAJ90LhcK0PGkyyZv/7q5Mhfag4/rogCeLNcn
MIWcADFGVC1a1mzcW+V1Nvc=
=GtN2
-----END PGP SIGNATURE-----

 

[bbxrider]

what is 'top-post' ???
actually don't understand how the eric roode and first sinan unur posts were
not subordinated to the post immediately above them,
i simply use reply-to-group and it always subordinates to the post i'm
responding to

[please don't top-post]

thanks for all the help and opinions i'm just self learning perl and
found some code at http://www.cgi101.com/class/ and some other
searching google groups actually i dont even know what cgi.pm and
cgi lite are but will surely find out

For CGI, type 'perldoc CGI' at a command prompt. CGI::Lite you would
need to install. Note that the names of Perl modules are case-sensitive.

i dont' mean to try and just steal code, but have found that seeing,
using and understanding examples really accelerates my learing curve

Absolutely. Reading decent code is one of the best ways to learn. You
do have to be sure your source is reliable, though: there is one hell
of a lot of very bad Perl floating around the web.

what i've since found is that the variable containing the form input
is in fact in the same order as the form this code keeps the
original order

I don't think this is guaranteed, by which I mean that it may happen
to work for you with your browser during this phase of the moon, but
under other circumstances it may well not. If you need to keep
separate track of the different paramaters, give them different
names. Change whatever generates them to put a number on the end, or
something.

Ben

--
For the last month, a large number of PSNs in the Arpa[Inter-]net have been
reporting symptoms of congestion ... These reports have been accompanied by an
increasing number of user complaints ... As of June,... the Arpanet contained
47 nodes and 63 links. [ftp://rtfm.mit.edu/pub/arpaprob.txt] *

(e-mail address removed)

 

[David H. Adler]

Eric Schwartz wrote:

[re: CGI.pm]

I very much dislike the aggressive way in which some people here
advocate the use of CGI, and the lack of faith that is shown in
people's own judge. The described attitude makes me suspicious and
less inclined to listen. How about that for a reason?

Looking at the question and the answer, in isolation at least, I'm going
to assume the use of "reason" there is irony.

dha