[23160] in Perl-Users-Digest
Perl-Users Digest, Issue: 5381 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Aug 17 21:05:45 2003
Date: Sun, 17 Aug 2003 18:05:09 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 17 Aug 2003 Volume: 10 Number: 5381
Today's topics:
Re: and why can't I do my own CGI? (aka ? the Platypus)
Re: CGI is not so hard (aka ? the Platypus)
Re: comp.lang.perl.open.discussion rfc in alt.config (aka ? the Platypus)
from epoch to date string (Farid Hamjavar UNM-CIRT)
Re: from epoch to date string <abigail@abigail.nl>
Re: Hudson River <noreply@gunnar.cc>
Re: Hudson River <tassilo.parseval@rwth-aachen.de>
Re: Hudson River <tassilo.parseval@rwth-aachen.de>
Re: Hudson River <flavell@mail.cern.ch>
Re: Hudson River <noreply@gunnar.cc>
Re: Hudson River <tim@vegeta.ath.cx>
Re: Hudson River <flavell@mail.cern.ch>
Re: Hudson River <abigail@abigail.nl>
Re: Hudson River <noreply@gunnar.cc>
Re: Hudson River <abigail@abigail.nl>
Re: Hudson River <noreply@gunnar.cc>
Re: Hudson River (ko)
Re: Hudson River <noreply@gunnar.cc>
Re: Hudson River <noreply@gunnar.cc>
Re: Hudson River <REMOVEsdnCAPS@comcast.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 18 Aug 2003 00:54:35 GMT
From: "David Formosa (aka ? the Platypus)" <dformosa@dformosa.zeta.org.au>
Subject: Re: and why can't I do my own CGI?
Message-Id: <slrnbk08ud.6cf.dformosa@dformosa.zeta.org.au>
On Sat, 16 Aug 2003 21:04:17 -0700, hudson
<scripts_you_know_the_drill_@hudsonscripting.com> wrote:
[...]
> And using soap via IO::Socket is so easy. So I posted up my little
> piece of code and people started calling me names.
If modules are so bad why are you using IO::Socket and not doing it
directly?
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
------------------------------
Date: Sun, 17 Aug 2003 22:24:07 GMT
From: "David Formosa (aka ? the Platypus)" <dformosa@dformosa.zeta.org.au>
Subject: Re: CGI is not so hard
Message-Id: <slrnbk0049.6cf.dformosa@dformosa.zeta.org.au>
On Sat, 16 Aug 2003 21:00:18 -0700, hudson
<scripts_you_know_the_drill_@hudsonscripting.com> wrote:
> On Sun, 17 Aug 2003 00:51:45 GMT, "David Formosa (aka ? the Platypus)"
><dformosa@dformosa.zeta.org.au> wrote:
[...]
> yes...but it is so cool to know soap or http and it is really pretty
> simple...
I don't write to be cool, I right to get results (and to some deggrey
to have fun). Re-impliementing something is not fun, unless of cause
your doing it as a learning exprences and even then its better to
throw away the code after you have finished.
>just read one or two RFC's and something about soap and then
> you can interface all you want via IO::Socket
I know enought about NNTP and usenet to post by telnetting directly to
the news port and typing stuff in. However I use a newsreader. Why?
Because I don't wish to go to that effort.
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
------------------------------
Date: Mon, 18 Aug 2003 00:28:21 GMT
From: "David Formosa (aka ? the Platypus)" <dformosa@dformosa.zeta.org.au>
Subject: Re: comp.lang.perl.open.discussion rfc in alt.config
Message-Id: <slrnbk07d7.6cf.dformosa@dformosa.zeta.org.au>
On Sun, 17 Aug 2003 19:08:35 GMT, Rocco Caputo <dngor@bellsouth.net> wrote:
[...]
> The usenet convention for "discussion" groups is to attach a -d to an
> existing group's name. This is usually reserved for newsgroups whose
> charters prohibit general discussion.
I think you mean .d rather then -d
> Following that convention, the group comp.lang.perl.misc-d would be more
> appropriate.
In usenet normally its the tendency to no subdevide underneath .misc
so this would most likely be comp.lang.perl.d
> comp.lang.perl.discussion.open
Creates an orphin hyrakey.
> comp.lang.perl.open-discussion
Ugly.
> comp.lang.perl.misc.according-to-hudson
Comes off a misc.
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
------------------------------
Date: Sun, 17 Aug 2003 23:11:19 +0000 (UTC)
From: hamjavar@unm.edu (Farid Hamjavar UNM-CIRT)
Subject: from epoch to date string
Message-Id: <bhp22n$2dbu$1@argo.unm.edu>
greetings,
is there a revers of this below -- in a one-liner format?
i.e. input to be `date` and output to be number of
seconds since epoch.
% perl -e 'print scalar localtime (1061161826), "\n"'
Sun Aug 17 17:10:39 MDT 2003
Thanks
Farid
------------------------------
Date: 18 Aug 2003 00:27:53 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: from epoch to date string
Message-Id: <slrnbk07c9.9l5.abigail@alexandra.abigail.nl>
Farid Hamjavar UNM-CIRT (hamjavar@unm.edu) wrote on MMMDCXXXVIII
September MCMXCIII in <URL:news:bhp22n$2dbu$1@argo.unm.edu>:
`' greetings,
`'
`' is there a revers of this below -- in a one-liner format?
`' i.e. input to be `date` and output to be number of
`' seconds since epoch.
`'
`' % perl -e 'print scalar localtime (1061161826), "\n"'
`' Sun Aug 17 17:10:39 MDT 2003
Dat lijkt me onmogelijk. Your number of seconds ends with '6', and
the reported date/time ends with '9' in the seconds range.
$ perl -e 'print scalar localtime (1061161826), "\n"'
Mon Aug 18 01:10:26 2003
which would be
Sun Aug 17 17:10:26 MDT 2003
Anyway, the reverse:
$ perl -MTime::Local -wle 'print timelocal 26, 10, 1, 18, 7, 103'
1061161826
Abigail
--
perl -e '* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
/ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /
% % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % %;
BEGIN {% % = ($ _ = " " => print "Just Another Perl Hacker\n")}'
------------------------------
Date: Mon, 18 Aug 2003 00:10:34 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Hudson River
Message-Id: <bhouhc$1o9jc$1@ID-184292.news.uni-berlin.de>
Tim Hammerquist wrote:
> Gunnar Hjalmarsson graced us by uttering:
>>[...] I just don't understand why the regulars, who so strongly
>>advocate the use of modules in general and CGI.pm in
>>particular, provoke such reactions over and over again. It's a
>>mystery to me why some people here make such a fuss about the
>>fact that some of us sometimes choose to parse form data using
>>a few lines of own code instead of using CGI.pm. You are lousy
>>missionaries. ;-)
>
> There are no laws, religious or otherwise, preventing you from
> parsing your own form data.
Okay, fine. :)
But since you replied to my initial post in this thread, Tim, please
allow me to call your attention to the topic I was *trying* to bring
up for discussion: It was *not* whether I'm *allowed* to write certain
code. It was rather the *tone* and the perceived *dogmatism* that is
used as soon as questions about the use of modules in general and
CGI.pm in particular are brought up.
Please see my latest reply to Randal, where I expanded on that topic.
> However, if you choose to reinvent the wheel, especially on that
> scale,
I have no intention to reinvent all the wheels that are covered by
CGI.pm. I'm actually using it in a couple of programs, and I'm likely
to use it more in the future, for instance if I need to handle file
uploads.
Another aspect: There may be very rational reasons for reinventing
wheels from time to time. See my reply to Alan in this thread, for
instance.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 17 Aug 2003 22:31:45 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: Hudson River
Message-Id: <bhovoh$3qd$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Gunnar Hjalmarsson:
> To return to my favorite topic: CGI.pm. Take a beginner who blindly
> follows the firm advise from most regulars here, and start doing his
> or her CGI by help of CGI.pm. One of the points with modules is that
> you "shall not re-invent wheels", since experts already have taken
> care of everything in a much better way than you ever could, right?
> Okay, doesn't that mean a *greater* risk that s/he refrains from
> learning the stuff you called our attention to above, compared to if
> s/he had started to explore CGI by re-inventing a few wheels?
No, this risk you mention is not a risk but a virtue. I have some
experience with reading RFC and specs. My experience is that I always
get them wrong the first couple of times. They somehow and implicitely
assume that you already know the stuff which they are supposed to
explain. They are a valuable reference but they are inadquate for
learning a concept.
The reason is that they are normally very condensed. They don't talk
about the implication that every specification has on the
implementation. They assume that the reader is experienced enough to
figure them out on his own. An easy example:
Take a fictious RFC that explains some sort of request from a client to
a server. It says the request may have a length of no more than 4096
bytes (actual length stored in an environment variable). And now
consider a relatively inexperienced programmer who wants to write a C
library for this kind of protocol. He sees the limit of 4096 chars and
immediately starts off with:
static char request[4096];
void read_request (void) {
int len = atoi(getenv("REQUEST_LEN"));
read(fileno(stdin), (void*)request, len);
}
This code is standards-conformant. Unfortunately it also contains a
large security hole that can easily be triggered when the client sends a
string longer than the allowed 4096. And there you have a first nice
buffer-overrun.
This example is slightly contrived. It used C instead of Perl because it
is a little easier to construct vulnerabilites in C. But it's also
possible for Perl (things like creating and handling tmp-files securely
e.g. needs consideration in any language). Anyway, it shows that even
understanding something doesn't automatically mean you should be allowed
to program it. That should be left to those having enough experience in
avoiding CERT advisories.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: 17 Aug 2003 22:36:23 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: Hudson River
Message-Id: <bhp017$41d$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Rafael Garcia-Suarez:
> Tassilo v. Parseval wrote in comp.lang.perl.misc :
>>
>> use CGI qw/:cgi/;
>>
>> if (request_method() eq 'GET') {
>> die_gracefully();
>> }
>
> That kind of thing is better done in an httpd.conf, for performance
> reasons. But not everyone can tweak one's server config...
A) that and B) a tweak to the server configuration would disallow it for
every script running on it (not sure about that actually, but I would
guess so).
I wonder though why one would want to allow only one method but not the
other one anyway. Especially when considering that CGI.pm has $POST_MAX
that can be used to restrict the length of requests.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Mon, 18 Aug 2003 00:34:39 +0200
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: Hudson River
Message-Id: <Pine.LNX.4.53.0308180015550.22560@lxplus009.cern.ch>
On Sun, Aug 17, Gunnar Hjalmarsson inscribed on the eternal scroll:
> Indeed an important distinction, Alan. To get it right, you do need to
> be aware of that. In other words, you need to know what you are doing.
[...]
> Okay, doesn't that mean a *greater* risk that s/he refrains from
> learning the stuff you called our attention to above, compared to if
> s/he had started to explore CGI by re-inventing a few wheels?
I think you're confusing the distinction between individual learning
studies, and practical solutions fit for a real-world CGI situation.
Both have their place in the scheme of things, but one needs to be
clear which is which.
When I started this game, back in Perl4 days, I used to write my own
decoding - copying what I would now categorise as cargo-cult code that
I found in existing scripts. As I learned more about the
practicalities, I started to use cgi-lib.pl. Subsequently I learned
yet more, and started to make the acquaintance of CGI.pm
Without wanting to brag, I think I could fairly say that I understand
CGI and HTTP issues at a level somewhat above the average for this
group - even if my Perl coding is rather pedestrian[1] - but that only
gives me even more reason to recommend using peer-reviewed modules to
anyone who's willing to ask. And when it comes to CGI, "warts and
all", CGI.pm is basically _the_ peer reviewed solution. Just look at
the fuss there's been about a typo in version 2.99. Where would you
enlist that amount of effort to help with some obscure typo in your
own hand-spun script, riddle me that?
all the best
[1] "Physicists code FORTRAN in any language" - original attribution
not known.
------------------------------
Date: Mon, 18 Aug 2003 00:58:49 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Hudson River
Message-Id: <bhp1br$1pevb$1@ID-184292.news.uni-berlin.de>
Tassilo v. Parseval wrote:
> The real question remains: Why is your own solution better than CGI?
That is not the question at all, since I never claimed that it is.
Claiming that was not the purpose with starting this thread.
I'm asking for some respect. Yes, modules *are* a good concept. Yes, I
*do* use modules. But ... let me quote a part from the message you
replied to that you did not quote:
> Gunnar Hjalmarsson wrote:
>> I reserve the right to decide, from case to case, if it's
>> motivated to make use of a module, whether it's CGI.pm or some other
>> module. I feel that I'm entitled to do so without automatically be
>> accused of using "bad" or "broken" code.
> CGI works just as well when used in a very restricting compartement.
I know. Actually, a few months ago the regulars in this group
pursuaded me to use CGI for that particular program, which btw is a
CPAN module under the CGI:: namespace (CGI::ContactForm), so I finally
changed it. :)
As I mentioned in another post, it was never my intention to discuss
that program in detail. In a reply to Tintin I gave two *examples* of
code in order to illustrate my thesis that some kind of Perl code can
easily be discussed here in a sober manner, while other kind of code
can not.
Unfortunately I think that the reactions to my simple
split /&/, $data
example have confirmed the thesis quite well. :(
CGI.pm is a sacred cow. Slaughter the sacred cow! (But keep CGI.pm, of
course...)
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 17 Aug 2003 16:01:11 -0700
From: Tim Hammerquist <tim@vegeta.ath.cx>
Subject: Re: Hudson River
Message-Id: <slrnbk02bs.c3o.tim@vegeta.ath.cx>
Gunnar Hjalmarsson graced us by uttering:
> But since you replied to my initial post in this thread, Tim,
> please allow me to call your attention to the topic I was
> *trying* to bring up for discussion:
The initial post of a thread is generally where discussions are
brought up. If a new discussion is desired and/or needed, it's
typically done in a new thread.
I've read this thread. I just chose to reply to this post.
> Please see my latest reply to Randal...
Have done.
> See my reply to Alan...
Have done.
Let me summarize this thread for anyone who might be joining us
late.
OP == Original Poster.
EE == Everyone Else
OP: I want to do A.
EE: Why? It's a bad idea. Use B.
OP: But with A I can do C.
EE: I see why you might want to do A, but B can already do C.
OP: But B can't do C the same way A can.
EE: No, you're right. It does it better, safer, and cleaner than A.
OP: I'm not impressed with all the reasoning and experience
you've shared with me.
EE: Um, ok.
OP: Why don't you see things my way?
EE: We've been doing this longer and heard many arguments from
many other people and have still not been convinced.
OP: You guys are just arrogant bastards.
EE: Possibly, but we've earned our arrogance.
OP: But why can't I do A?!
EE: You can. We just think it's a bad idea and can't see
supporting you in what has previously always been a fatally
flawed endeavour.
OP: But WHY don't you want to help me?
EE: You're not asking for help.
OP: But why won't you believe in my obviously well-thought-out ideas?
EE: Because we don't think you've really thought them out far enough.
OP: You guys are a bunch of fascists! See my replies where I say
as much to regular posters D, E, and F.
EE: No thanks.
Tim Hammerquist
--
Q: Puff, what is best in sys admin?
A: To crush your script kiddies, see them coredump before you,
hear the stack protector warnings of their failed overflows.
-- From an OpenBSD Journal post
------------------------------
Date: Mon, 18 Aug 2003 00:53:48 +0200
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: Hudson River
Message-Id: <Pine.LNX.4.53.0308180043590.22560@lxplus009.cern.ch>
On Mon, Aug 17, Tassilo v. Parseval inscribed on the eternal scroll:
> I wonder though why one would want to allow only one method but not the
> other one anyway.
In principle, the key to that is idempotence. Although there can be
other practical issues involved.
If you're implementing a form which performs a non-idempotent action,
such as casting a vote, ordering a flight ticket, etc. then it would
be wise to refuse to accept a GET submission. I think you'll find
more about it in RFC2616.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
> Especially when considering that CGI.pm has $POST_MAX
> that can be used to restrict the length of requests.
With respect, I think you're focussing on a peripheral issue.
------------------------------
Date: 17 Aug 2003 23:18:44 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: Hudson River
Message-Id: <slrnbk03ak.9l5.abigail@alexandra.abigail.nl>
Tassilo v. Parseval (tassilo.parseval@rwth-aachen.de) wrote on
MMMDCXXXVIII September MCMXCIII in <URL:news:bhot4i$27o$1@nets3.rz.RWTH-Aachen.DE>:
,,
,, The real question remains: Why is your own solution better than CGI?
,, CGI works just as well when used in a very restricting compartement.
Actually, it has always amazed me why using a dinosaur module like CGI
is considered "good programming" if all you need is parameter parsing.
I'm not at all surprised that people use the commonly see 'read_parse'
subroutine (I wonder why people keep calling that 'handrolled' - it's the
same code you see over and over again. This is code reuse, although it's
code that doesn't cover all cases (not that I can recall ever seeing a
posting here complaining that not all cases are covered)). 'read_parse'
is about 10 lines of code, and not to hard to understand. The manual of
CGI.pm is 3226 lines. And it's doing all kinds of stuff that isn't at
all CGI related. I'd expect a new version of CGI.pm that sends out
mail any day now.
I remember the days when you could write the entire CGI specification
on less than one sheet of A4 paper. CGI is *simple*, but CGI.pm isn't.
And yes, I've "rolled my own parsing" as well, and it certainly didn't
cover all cases either. It doesn't always have to.
Abigail
--
$=-=4*++$|;{print$"x--$==>"\@\x7Fy~*kde~box*Zoxf*Bkiaox \r"
^
$/x24if!select$,,$,,$,,join+q=.==>$^W=>$|;$=&&redo}sleep$|;
------------------------------
Date: Mon, 18 Aug 2003 01:23:17 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Hudson River
Message-Id: <bhp2po$1pgo0$1@ID-184292.news.uni-berlin.de>
Alan J. Flavell wrote:
> On Sun, Aug 17, Gunnar Hjalmarsson inscribed on the eternal scroll:
>> Indeed an important distinction, Alan. To get it right, you do
>> need to be aware of that. In other words, you need to know what
>> you are doing.
>
> [...]
>
>> Okay, doesn't that mean a *greater* risk that s/he refrains from
>> learning the stuff you called our attention to above, compared to
>> if s/he had started to explore CGI by re-inventing a few wheels?
>
> I think you're confusing the distinction between individual
> learning studies, and practical solutions fit for a real-world CGI
> situation.
In a way I did mix them up, and that was intentionally.
How often do all the regulars, who so energetically advocate the use
of modules, mention the _desirable_ in "reinventing wheels" in order
to gain knowledge?
> Without wanting to brag, I think I could fairly say that I
> understand CGI and HTTP issues at a level somewhat above the
> average for this group
No doubt you do.
I wonder if that had been the case if Perl 5 and CGI.pm had been
available when you started, while experienced programmers had enforced
you to use CGI to begin with. ;-)
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 17 Aug 2003 23:31:36 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: Hudson River
Message-Id: <slrnbk042o.9l5.abigail@alexandra.abigail.nl>
Eric J. Roode (REMOVEsdnCAPS@comcast.net) wrote on MMMDCXXXVIII September
MCMXCIII in <URL:news:Xns93DA9A7DF7A42sdn.comcast@206.127.4.25>:
==
== Apparently, many people think "nobody's going to access this page except
== via the form that I have written, so I can do it any damn way I please."
== That attitude limits the flexibility of people like me.
What a sillyness. A form defines an interface. It tells you which input
names there are. It tells you the URL to submit it to. It tells you
whether to use GET or POST.
Now, you as a submitter may be flexible, but it's silly to assume that
if you invent your own input names, treat radio-buttons as text input
or make up your own URL to submit to, that it's going to work.
It's like normal programming. If you use a library, stick to its API.
If you make something up, don't be surprised it won't work.
Abigail
--
perl -wle'print"Κυστ αξοτθες Πεςμ Θαγλες"^"\x80"x24'
------------------------------
Date: Mon, 18 Aug 2003 01:40:12 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Hudson River
Message-Id: <bhp3pf$1k346$1@ID-184292.news.uni-berlin.de>
Abigail wrote:
> Actually, it has always amazed me why using a dinosaur module like
> CGI is considered "good programming" if all you need is parameter
> parsing.
<snip>
> And yes, I've "rolled my own parsing" as well, and it certainly
> didn't cover all cases either. It doesn't always have to.
Wow, a _regular_ who admits that she relies on her own judge from time
to time.
Thanks, Abigail! :)
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 17 Aug 2003 16:55:38 -0700
From: kuujinbo@hotmail.com (ko)
Subject: Re: Hudson River
Message-Id: <92d64088.0308171555.635b1fee@posting.google.com>
merlyn@stonehenge.com (Randal L. Schwartz) wrote in message news:<2dc316d7fc94cff23f990de35d21b0be@news.teranews.com>...
> >>>>> "Gunnar" == Gunnar Hjalmarsson <noreply@gunnar.cc> writes:
>
> Gunnar> Now, let's say that I have some code that deals with form data from
> Gunnar> STDIN, including:
>
> Gunnar> for (split /&/, $data)
>
> Gunnar> If I would post it here, somebody would most certainly claim it to be
> Gunnar> broken since I don't include ';' when splitting.
>
> Gunnar> Then, if I would explain that in *my* program, data is only submitted
> Gunnar> from a form using the POST method, some people here would *not* accept
> Gunnar> my explanation, but still claim that the code is "broken", refer to
> Gunnar> "Joe newbie" etc.
>
> No. You don't have control over how data is submitted to your form.
> And by limiting flexibility artificially, you are breaking legitimate
> users who might want to create a bookmark for a particular form
> submission, for example.
>
> Why Hand Code a limited solution, when a flexible solution is available
> to you with the simple phrase "use CGI qw(param);"?
>
> It's not a sacred cow. It's the collective voices of people WHO HAVE
> BEEN BURNED BY HAND CODING.
>
> Get it? Voice of reason. Voice of experience. Pay attention.
I'm not sure that the form example was a good way to make your point,
Gunnar. Anyone can submit anything they want to a form. In the
simplest case, someone makes a local copy of the form, changes all the
parameters locally, and then submits the edited copy to the web
server. Also, look at the LWP bundle of modules on CPAN
(http://search.cpan.org/author/GAAS/libwww-perl-5.69/lib/LWP.pm),
especially LWP::UserAgent, to see how easily it is to programmatically
send arbitrary data with forms, not to mention arbitrarily set HTTP
REFERER, USER_AGENT, etc.
On a side note, I'm a self-taught coder and semi-regular 'lurker' on
this group. I rarely post, and use the discussions as a learning tool.
I search the group pretty much exclusively using Google, not a
newsreader - I know, I probably should be using a newsreader...
Anyway, this guy has created a *lot* of noise lately. It's probably
presumptuous of me to request/suggest, especially since some of the
posts haven't even been civil, but could the experts/regulars just
ignore any of his subsequent posts? With all of your knowledge to
share, it just seems like a waste to continue any existing/new
threads. He seems pretty set in *his* ways, not the other way around,
which is what has been implied.
I would think even newbies can figure out what's going on with someone
who answers his own post/rants:
(http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&threadm=bho4uf%244i2%241%40ichaos.ichaos-int&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.lang.perl.misc).
Thanks - keith
------------------------------
Date: Mon, 18 Aug 2003 02:14:10 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Hudson River
Message-Id: <bhp5p6$1ntm4$1@ID-184292.news.uni-berlin.de>
ko wrote:
> I'm not sure that the form example was a good way to make your
> point, Gunnar. Anyone can submit anything they want to a form.
True. But the script does not necessarily need to parse anything.
Tassilo gave an example of that, btw.
Anyway, I won't prolong the discussion about my form example.
> Anyway, this guy has created a *lot* of noise lately. It's probably
> presumptuous of me to request/suggest, especially since some of
> the posts haven't even been civil, but could the experts/regulars
> just ignore any of his subsequent posts? With all of your knowledge
> to share, it just seems like a waste to continue any existing/new
> threads. He seems pretty set in *his* ways, not the other way
> around, which is what has been implied.
Hrrmm... With all respect, Keith, could you please clarify who you are
referring to with the expression "this guy"? My name is Gunnar, I
started this thread, and I'm not the same person as is mentioned in
the subject line of this thread.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Mon, 18 Aug 2003 02:42:52 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Hudson River
Message-Id: <bhp7f0$1nd4j$1@ID-184292.news.uni-berlin.de>
Tim Hammerquist wrote:
> Let me summarize this thread for anyone who might be joining us
> late.
>
> OP == Original Poster.
> EE == Everyone Else
>
> OP: I want to do A.
> EE: Why? It's a bad idea. Use B.
> OP: But with A I can do C.
> EE: I see why you might want to do A, but B can already do C.
> OP: But B can't do C the same way A can.
> EE: No, you're right. It does it better, safer, and cleaner than A.
> OP: I'm not impressed with all the reasoning and experience
> you've shared with me.
> EE: Um, ok.
> OP: Why don't you see things my way?
> EE: We've been doing this longer and heard many arguments from
> many other people and have still not been convinced.
> OP: You guys are just arrogant bastards.
> EE: Possibly, but we've earned our arrogance.
> OP: But why can't I do A?!
> EE: You can. We just think it's a bad idea and can't see
> supporting you in what has previously always been a fatally
> flawed endeavour.
> OP: But WHY don't you want to help me?
> EE: You're not asking for help.
> OP: But why won't you believe in my obviously well-thought-out ideas?
> EE: Because we don't think you've really thought them out far enough.
> OP: You guys are a bunch of fascists! See my replies where I say
> as much to regular posters D, E, and F.
> EE: No thanks.
Even if I disapprove of the accuracy of your summary, I hope you had
fun when you wrote it.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sun, 17 Aug 2003 19:53:45 -0500
From: "Eric J. Roode" <REMOVEsdnCAPS@comcast.net>
Subject: Re: Hudson River
Message-Id: <Xns93DAD47C0586Bsdn.comcast@206.127.4.25>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
"Alan J. Flavell" <flavell@mail.cern.ch> wrote in
news:Pine.LNX.4.53.0308172116071.2624@lxplus003.cern.ch:
> On Sun, Aug 17, Eric J. Roode inscribed on the eternal scroll:
>
>> You can't have naked ampersands in URLs in strict HTML.
>
> To nit-pick over terminology: you certainly _can_ have naked
> ampersands "in URLs" - indeed, actual forms submission via GET
> absolutely depends on it.
>
> What you can't have are naked ampersands in URL *references* in HTML,
> of the kind which occur in the attribute values for href= or src= etc.
> in HTML.
You're right, of course; I was speaking loosely.
>
>> Losers.
>
> I think so too, but there's always Sturgeon's Law on the side of our
> detractors.
:-)
>
>> That attitude limits the flexibility of people like me.
>
> They would like that, you see.
Nah, I think they just don't think.
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN xxx SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBP0AjemPeouIeTNHoEQJJ7gCgmOehpLwiZ9MhlP7A+KQUyGaOM54AoJXV
TkknFlRHNEct1fOMfiz7PO11
=bntV
-----END PGP SIGNATURE-----
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 5381
***************************************
