[13884] in Perl-Users-Digest
Perl-Users Digest, Issue: 1294 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Nov 8 14:18:00 1999
Date: Mon, 8 Nov 1999 11:17:46 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <942088665-v9-i1294@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Mon, 8 Nov 1999 Volume: 9 Number: 1294
Today's topics:
C++ Free Compiler for Win32? <gamemaestro@hotmail.com>
Re: C++ Free Compiler for Win32? <gellyfish@gellyfish.com>
Re: C++ Free Compiler for Win32? <rhomberg@ife.ee.ethz.ch>
Re: C++ Free Compiler for Win32? <theglauber@my-deja.com>
calling C-commands in perl <r7768c@email.sps.mot.com>
Re: calling C-commands in perl <rhomberg@ife.ee.ethz.ch>
cgi debug <rsodre@hotmail.com>
Re: cgi debug <rootbeer@redcat.com>
Re: cgi debug <cassell@mail.cor.epa.gov>
Re: cgi debug (Kragen Sitaker)
CGI FAQ discussion, was Re: Problem with perl and MSIE5 <flavell@mail.cern.ch>
Re: CGI FAQ discussion, was Re: Problem with perl and M (Abigail)
Re: CGI FAQ discussion, was Re: Problem with perl and M <uri@sysarch.com>
Re: CGI FAQ discussion, was Re: Problem with perl and M (Kragen Sitaker)
Re: CGI FAQ discussion, was Re: Problem with perl and M <gellyfish@gellyfish.com>
Re: CGI FAQ discussion, was Re: Problem with perl and M <flavell@mail.cern.ch>
Re: CGI FAQ discussion, was Re: Problem with perl and M <uri@sysarch.com>
Re: CGI FAQ discussion, was Re: Problem with perl and M (Kragen Sitaker)
Re: CGI FAQ discussion, was Re: Problem with perl and M <flavell@mail.cern.ch>
Re: CGI FAQ discussion, was Re: Problem with perl and M voltemand@earthlink.net
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 9 Nov 1999 06:55:35 -0800
From: "Gamemaestro" <gamemaestro@hotmail.com>
Subject: C++ Free Compiler for Win32?
Message-Id: <942072854.254189@sj-nntpcache-2.cisco.com>
I just started learning Perl, and was wondering if there might be a
shareware C++ compiler for a win 32 machine, which I could download.
Gamemaestro
------------------------------
Date: 8 Nov 1999 15:27:17 GMT
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: C++ Free Compiler for Win32?
Message-Id: <3826ebd5_1@newsread3.dircon.co.uk>
Gamemaestro <gamemaestro@hotmail.com> wrote:
> I just started learning Perl, and was wondering if there might be a
> shareware C++ compiler for a win 32 machine, which I could download.
>
Er sorry you just started learning *Perl* so you want to get a *C++*
compiler er right ?
<http://www.cygnus.com>
/J\
--
"The Spice Girls don't care if I like them or not because I'm not twelve"
- Germaine Greer
------------------------------
Date: Mon, 08 Nov 1999 16:38:33 +0100
From: Alex Rhomberg <rhomberg@ife.ee.ethz.ch>
Subject: Re: C++ Free Compiler for Win32?
Message-Id: <3826EE79.F411118A@ife.ee.ethz.ch>
Gamemaestro wrote:
>
> I just started learning Perl, and was wondering if there might be a
> shareware C++ compiler for a win 32 machine, which I could download.
should it be shareware or should it be free?
AFAIK, gcc is available for win32, but it isn't shareware. It's free.
And it has nothing to do with Perl
- Alex
------------------------------
Date: Mon, 08 Nov 1999 17:36:36 GMT
From: The Glauber <theglauber@my-deja.com>
To: "Gamemaestro" <gamemaestro@hotmail.com>
Subject: Re: C++ Free Compiler for Win32?
Message-Id: <8071n4$97n$1@nnrp1.deja.com>
In article <942072854.254189@sj-nntpcache-2.cisco.com>,
"Gamemaestro" <gamemaestro@hotmail.com> wrote:
> I just started learning Perl, and was wondering if there might be a
> shareware C++ compiler for a win 32 machine, which I could download.
There's a few out there, and i'm sure you'll get better replies asking
in one of the C/C++ newsgroups.
However, if what you want is to use your Win32 machine to learn Perl,
don't compile it from the sources; download the excellent version from
www.activestate.com.
good luck
glauber
--
Glauber Ribeiro
theglauber@my-deja.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 08 Nov 1999 12:04:52 +0100
From: Thomas Benedek <r7768c@email.sps.mot.com>
Subject: calling C-commands in perl
Message-Id: <3826AE54.2EE6E031@email.sps.mot.com>
Hello everybody!
I tried to do the Example1 in the perlxstut manpage (printing Hello World! by calling a c-function from a perl script).
Everything worked up to the (I think) last step.
I got the following error message :
thomasb_rawaki 99 tst
Can't load 'blib/arch/auto/hellow/hellow.so' for module hellow: ld.so.1: /tools/gnu/bin/perl: fatal: relocation error: file blib/arch/auto/hellow/hellow.so: symbol Perl_stack_sp: referenced symbol not
found at /tools/gnu/lib/perl5/DynaLoader.pm line 140.
at blib/lib/hellow.pm line 19
BEGIN failed--compilation aborted at tst line 4.
where tst is
#!/tools/gnu/bin/perl
use ExtUtils::testlib;
use hellow;
hellow::hello();
and hellow is the name of the directory that has been created by h2xs.
I think it is a problem with the DynaLoader, is it?
I must add that I don't have root permissions on this system so I cant copy into /tools/gnu/lib/perl5.
I read in DynaLoader.pm that there are often problems with the dynamic extension loading at this point.
Thanx for Your help
Thomas
---------------------
Thomas Benedek
---------------------
------------------------------
Date: Mon, 08 Nov 1999 14:26:33 +0100
From: Alex Rhomberg <rhomberg@ife.ee.ethz.ch>
Subject: Re: calling C-commands in perl
Message-Id: <3826CF89.A0B64AF9@ife.ee.ethz.ch>
Thomas Benedek wrote:
>
> Hello everybody!
>
> I tried to do the Example1 in the perlxstut manpage (printing Hello World!
> by calling a c-function from a perl script).
> Everything worked up to the (I think) last step.
>
> I got the following error message :
>
> thomasb_rawaki 99 tst
> Can't load 'blib/arch/auto/hellow/hellow.so' for module hellow: ld.so.1:
> /tools/gnu/bin/perl: fatal: relocation error: file
> blib/arch/auto/hellow/hellow.so: symbol Perl_stack_sp: referenced symbol not
> found at /tools/gnu/lib/perl5/DynaLoader.pm line 140.
Dynaloader seems to search the file in ./blib etc.etc. you seem to be in
the parent dir of you build directory, so the file is not found
Try to edit the test.pl file as is suggested in the perlxstut manpage.
And try to keep your lines at 80 chars.
> I think it is a problem with the DynaLoader, is it?
No, it's a problem with your current directory
> I must add that I don't have root permissions on this system so I cant copy
> into /tools/gnu/lib/perl5.
> I read in DynaLoader.pm that there are often problems with the dynamic
> extension loading at this point.
Though I do have root on a subset of the computers our project should
run on, my xs stuff is clearly project specific and I therefore do not
want to clutter perls installation directory.
I still want to be able to use perl's platform detection. My fix for
this was:
in Makefile.PL, I added
PREFIX => '/home/rhomberg/my/perl/extensions',
Then I have to tell perl to load from there too and keep the platform
detection:
use lib "/home/rhomberg/my/perl/extensions/lib/site_perl/5.005";
use model_to_SV;
This adds other extension lib to @INC, keeping platform autodetection
-Alex
------------------------------
Date: Fri, 05 Nov 1999 19:13:32 GMT
From: Rogerio Sodre <rsodre@hotmail.com>
Subject: cgi debug
Message-Id: <7vva8p$3oa$1@nnrp1.deja.com>
I have some sites at VirtualAvenue free server and use perl cgi a lot.
But their support people are a little stupid, they say that their
support is just to ensure that my site is up and can't answer any cgi
question.
So, can anyone please tell me how can I debug a perl cgi script that's
running on my server? If there's an error on the script, I just get
"Server error" or something.
Is there a way di direct STDERR to some file? I tried to put at
"#!/usr/local/bin/perl 2>err.log" but it won't work. Anyone knows how do
I do this? I know picas (nothing) of shebang, as you can see...
Thanks
Rogerio
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 5 Nov 1999 12:51:59 -0800
From: Tom Phoenix <rootbeer@redcat.com>
Subject: Re: cgi debug
Message-Id: <Pine.GSO.4.10.9911051251420.29670-100000@user2.teleport.com>
On Fri, 5 Nov 1999, Rogerio Sodre wrote:
> So, can anyone please tell me how can I debug a perl cgi script that's
> running on my server?
When you're having trouble with a CGI program in Perl, you should first
look at the please-don't-be-offended-by-the-name Idiot's Guide to solving
such problems. It's available on CPAN.
http://www.perl.com/CPAN/
http://www.cpan.org/
http://www.cpan.org/doc/FAQs/cgi/idiots-guide.html
http://www.cpan.org/doc/manual/html/pod/
Hope this helps!
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: Fri, 05 Nov 1999 15:01:17 -0800
From: David Cassell <cassell@mail.cor.epa.gov>
Subject: Re: cgi debug
Message-Id: <382361BD.2EDA7625@mail.cor.epa.gov>
Rogerio Sodre wrote:
[snip]
> So, can anyone please tell me how can I debug a perl cgi script that's
> running on my server? If there's an error on the script, I just get
> "Server error" or something.
You'll probably want to look into the CGI::Carp module, which
can do some of these things for you. I believe Tom Phoenix
showed some code in this newsgroup only a couple months ago to
help with this sort of problem, so you can search the deja.com
archives for that.
> Is there a way di direct STDERR to some file? I tried to put at
> "#!/usr/local/bin/perl 2>err.log" but it won't work. Anyone knows how do
> I do this? I know picas (nothing) of shebang, as you can see...
No, that won't work. To learn more about what you on the
shebang line read the perlrun pages. If you have Perl on your
own machine, you can read about this on your own system using
the perldoc program which comes with Perl.
David
--
David Cassell, OAO cassell@mail.cor.epa.gov
Senior computing specialist
mathematical statistician
------------------------------
Date: Sat, 06 Nov 1999 20:28:12 GMT
From: kragen@dnaco.net (Kragen Sitaker)
Subject: Re: cgi debug
Message-Id: <wb0V3.48762$23.1847802@typ11.nn.bcandid.com>
In article <7vva8p$3oa$1@nnrp1.deja.com>,
Rogerio Sodre <rsodre@hotmail.com> wrote:
>I have some sites at VirtualAvenue free server and use perl cgi a lot.
>But their support people are a little stupid, they say that their
>support is just to ensure that my site is up and can't answer any cgi
>question.
Well, that's not surprising. You might see if you can ask them where
the error_log file is located, though.
>So, can anyone please tell me how can I debug a perl cgi script that's
>running on my server? If there's an error on the script, I just get
>"Server error" or something.
CGI::Carp, as someone suggested, could be helpful.
>Is there a way di direct STDERR to some file?
open(STDERR, ">>err.log) or do {
print "Content-Type: text/plain
Failed to open error log: $!.
";
exit 1;
};
--
<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
Tue Nov 02 1999
6 days until the Internet stock bubble bursts on Monday, 1999-11-08.
<URL:http://www.pobox.com/~kragen/bubble.html>
------------------------------
Date: Sat, 6 Nov 1999 14:57:06 +0100
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: CGI FAQ discussion, was Re: Problem with perl and MSIE5
Message-Id: <Pine.HPP.3.95a.991106145306.28531B-100000@hpplus01.cern.ch>
[corrected posting with Supersedes header - sorry]
On Fri, 5 Nov 1999, David Cassell wrote:
> See? You do need to get these FAQs corrected.
OK, so I've opened my big mouth, I suppose I'd better put my cards on
the table.
First an organisational point. If I follow Tom Phoenix's
regularly-posted pointer to the FAQs: http://www.cpan.org/doc/FAQs/
, I find myself at
<URL:
http://www.perl.com/CPAN-local/doc/FAQs/FAQ/PerlFAQ.html#
How_do_I_redirect_to_another_pag >
with a title that says I'm reading something that was last revised
1997/03/17.
However, the actual version that I was criticising was the one
found in a recent Perl distribution, and also to be found at
<URL:
http://www.perl.com/pub/doc/manual/html/pod/perlfaq9.html#
How_do_I_redirect_to_another_pag >
[ Shouldn't this version discrepancy be resolved? ]
Here is a plain-text rendering of the FAQ under review:
----
How do I redirect to another page?
Instead of sending back a Content-Type as the headers of your reply,
send back a Location: header. Officially this should be a URI: header,
so the CGI.pm module (available from CPAN) sends back both:
Location: http://www.domain.com/newpage
URI: http://www.domain.com/newpage
Note that relative URLs in these headers can cause strange effects
because of ``optimizations'' that servers do.
$url = "http://www.perl.com/CPAN/";;
print "Location: $url\n\n";
exit;
To be correct to the spec, each of those "\n" should really each be
"\015\012", but unless you're stuck on MacOS, you probably won't notice.
----
0: Disclaimer
The last thing I am aiming for is a stand-up argument with the respected
authors, and as a relative newcomer to the Perl group I hope this won't
be taken amiss. However, a couple of emails and your posting have
suggested that this is a useful thing for me to do, so I'll give my best
effort at it. I am, of course, aware that there are other CGI-related
FAQ documents; I am just discussing this specific FAQ from perlfaq9.
Since cross-posting to c.i.w.a.cgi is inhibited by its automoderation
bot, I plan to post a copy of this to that group for discussion, and
try to boil down the result of discussions as best we can.
I must stress that the verbose stuff that I offer here for discussion is
NOT, repeat NOT, in itself a proposal for a new version of the FAQ. At
the end I will make a very terse proposal, although I can see that some
would favour dismissing this FAQ entirely from perlfaq.
1. Background and authoritative resources.
The specification of the CGI is found originally at
hoohoo.ncsa.uiuc.edu, and has served us well for many years, but it is
unsatisfactory in a number of respects as it leaves a number of
significant details uncodified.
For best current practice I would prefer to cite K.Coar's draft RFC
for CGI/1.1, see http://web.golux.com/coar/cgi/ , see e.g
http://web.golux.com/coar/cgi/draft-coar-cgi-v11-03-clean.html
The specifications of HTTP/1.0 and 1.1 are in their respective
RFCs, rfc1945 and rfc2616.
2. What's wrong in general terms with the current FAQ?
- it's off-topic, since it addresses some issues that are CGI-specific
and have nothing to do with the Perl language as such
- it fails to call attention to doing it with CGI.pm, which is surely
the safest approach for anyone who needs to follow the FAQ
- it fails to cite any of the authoritative specifications, thus it
fails the principle of "teaching to fish" instead of "handing out fish".
- it appears to be raising technical issues that are generic to
CGI scripts and have nothing specifically to do with redirecting.
- it seems to be confused about the distinction between the CGI
specification and the HTTP specification (and by implication about
the distinction between normal and NPH scripts)
- It omits to mention the possibility of influencing the status, e.g
to show that the redirection is permanent (301) rather than the default
which is documented to be 302 (temporary).
- it omits to mention the complications of issuing a redirection
in response to a POST transaction - a complex problem in which there
are incompatibilities between HTTP/1.0 and HTTP/1.1 specifications,
and between what happens in practice and what the specifications say
ought to happen.
3. What's wrong specifically with the answers given?
a. It is claimed that the response _ought_ to be a URI: response. I can
find no authoritative support for this claim. Both the NCSA and the
Coar specs document the proper response for producing an actual
redirection transaction as being a Location: header specifying an
absolute URI, optionally with a fragment-id. See for example
http://web.golux.com/coar/cgi/draft-coar-cgi-v11-03-clean.html#7.2.1.2
The optional URI header is documented in HTTP/1.0 rfc1945 D.2.10:
D.2.10 URI
The URI entity-header field may contain some or all of the Uniform
Resource Identifiers (Section 3.2) by which the Request-URI resource
can be identified. There is no guarantee that the resource can be
accessed using the URI(s) specified.
This appears to be informatory only, and in no way is it a request for
the server to perform a redirection. The correct (HTTP) protocol for
performing a redirection is an appropriate status-30x response in
conjunction with an HTTP header specifying an absolute URI. The correct
(CGI) protocol for performing a redirection is a Location: CGI response
specifying an absolute URI, optionally with a fragment-id: the server
will supply the default 302 status if the CGI script does not set one.
b. It is claimed that "relative URLs in these headers can cause strange
effects", and there is some obscure reference to "optimizations".
BUT the CGI specification states clearly and unambiguously what shall
happen in response to two different kinds of URL in the Location: CGI
response, one of which MUST produce a network redirection transaction
(which is therefore what is wanted here), and one of which is forbidden
to produce one (it's what's sometimes referred to as an "internal
redirection"). Neither of these correct responses uses a "relative URL"
in the strict sense: the script must provide either an absolute URI with
optional fragment-id, or, an absolute path within the server's URI space
(to quote the exact words of the draft RFC), and the results are firmly
specified, there is absolutely no scope for servers to implement
"optimizations".
c. The FAQ claims, in effect, that newlines have to be represented
according to the HTTP spec. The CGI spec says this is wrong, as we
have just been discussing on the group. And anyway this has nothing
specifically to do with issuing a redirection response.
-----
Proposal A. This specific FAQ, as corrected.
How do I redirect to another page?
The easiest way to get this right is to use the appropriate feature
of the CGI.pm module.
If you insist on programming it yourself, the following notes may be
helpful.
Instead of sending back a Content-Type as the header of your reply,
send back a Location: header speifying an absolute URI and optionally a
fragment-id.
Location: http://www.domain.com/newpage
If you wish the redirection to use a status other than the default
redirection status 302 (temporary redirection), you may provide the
status explicitly (in a normal, non-NPH script, this would be done by
sending a Status: in the CGI response).
The response should in all other respects conform to the CGI
specification.
Sending a redirection in response to a POST transaction is complex, due
to incompatibilities between HTTP/1.0 and 1.1 specifications, and
discrepancies in implementations. It is beyond the scope of this FAQ.
-----
It may however be cogently argued that this FAQ has no business being in
the Perl FAQ at all. Or that it should be stripped of even more detail
and should say nothing more than "do it with CGI.pm" or "refer to the
CGI specification of the Location: response".
What is closer to Perl however would be a proper explanation of how
a Perl script written to the CGI is supposed to return a response.
-----
Proposal B. (as addition or alternative)
Q: How does a Perl CGI script return a response?
A: The easiest way of handling this is to use the CGI.pm module
to take care of the details for you.
There are two distinct kinds of CGI script, the normal kind and the
Non-Parsed Headers kind. The method of distinguishing between them is
implementation defined, so you must consult the documentation for the
server that you use to discover which kind(s) it supports and how you
should tell the server which kind you want to use. With NCSA or Apache
servers, NPH scripts must be given names which begin with "nph-".
Normal (i.e non-NPH) scripts are much easier to handle, although there
may be a few obscure situations that can only be tackled by using NPH
scripts. Familiarity with the HTTP protocols is essential for
successful use of the latter: this lies outside the scope of this FAQ.
The correct forms of response from a CGI script are documented in the
CGI specification. Note that with a normal, non-NPH, script, the CGI
specification permits any of the common end-of-line conventions to be
used, so you may use "\n" in Perl on any platform.
In an NPH script, you are required to produce correct HTTP protocol
headers. The HTTP specification calls on servers to use CR+LF as the
only valid end-of-line representation (although it advises clients to be
tolerant of other conventions), and so it would seem advisable to use
binary output mode, and to represent newlines with "\015\012" on all
platforms in this situation, to assure proper portability.
Do not confuse the CGI specification with the HTTP specification: the
similarities are intentional, but can sometimes be misleading.
[And then cite the URLs of the respective documents!!!]
-----
Hope that helps.
------------------------------
Date: 6 Nov 1999 09:39:21 -0600
From: abigail@delanet.com (Abigail)
Subject: Re: CGI FAQ discussion, was Re: Problem with perl and MSIE5
Message-Id: <slrn828j47.2i1.abigail@alexandra.delanet.com>
Alan J. Flavell (flavell@mail.cern.ch) wrote on MMCCLVIII September
MCMXCIII in <URL:news:Pine.HPP.3.95a.991106145306.28531B-100000@hpplus01.cern.ch>:
##
I've not much to add, since you are, as usual, more than correct, except:
## It may however be cogently argued that this FAQ has no business being in
## the Perl FAQ at all. Or that it should be stripped of even more detail
## and should say nothing more than "do it with CGI.pm" or "refer to the
## CGI specification of the Location: response".
I would even say "CGI.pm has no business in being part of the main
perl distribution".
It is sometimes hard to argue that Perl isn't CGI and that CGI is
off-topic in this group, but distribute CGI.pm anyway.
Abigail
--
perl -e '* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
/ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /
% % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % %;
BEGIN {% % = ($ _ = " " => print "Just Another Perl Hacker\n")}'
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
------------------------------
Date: 06 Nov 1999 12:52:07 -0500
From: Uri Guttman <uri@sysarch.com>
Subject: Re: CGI FAQ discussion, was Re: Problem with perl and MSIE5
Message-Id: <x7g0yj33ug.fsf@home.sysarch.com>
>>>>> "A" == Abigail <abigail@delanet.com> writes:
A> I would even say "CGI.pm has no business in being part of the main
A> perl distribution".
logically that is correct. but practically it is a good idea. too many
newbies wouldn't use it if it were not in the core. as it is they still
don't but now you can say they have it and they don't have to learn how
to use cpan (which they shoulc anyway).
A> It is sometimes hard to argue that Perl isn't CGI and that CGI is
A> off-topic in this group, but distribute CGI.pm anyway.
no, but perl is the most popular cgi language with one of the best cgi
modules. so catering to that is small potatoes.
there still has to be created a perl SDK with many of the more popular
and useful modules already built with perl for many common platforms.
that would make creating turnkey systems with perl that much easier.
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
------------------------------
Date: Sat, 06 Nov 1999 21:40:04 GMT
From: kragen@dnaco.net (Kragen Sitaker)
Subject: Re: CGI FAQ discussion, was Re: Problem with perl and MSIE5
Message-Id: <Ue1V3.48853$23.1855758@typ11.nn.bcandid.com>
In article <Pine.HPP.3.95a.991106145306.28531B-100000@hpplus01.cern.ch>,
Alan J. Flavell <flavell@mail.cern.ch> wrote:
>In an NPH script, you are required to produce correct HTTP protocol
>headers. The HTTP specification calls on servers to use CR+LF as the
>only valid end-of-line representation (although it advises clients to be
>tolerant of other conventions), and so it would seem advisable to use
>binary output mode, and to represent newlines with "\015\012" on all
>platforms in this situation, to assure proper portability.
Apache 1.3's FAQ claims that (a) prior to 1.3, you needed to use
nph-scripts to get unbuffered output, and (b) "today, the only
difference between nph-scripts and normal scripts is that nph-scripts
require the full headers to be sent".
You'd think the documentation for mod_cgi would explain further, but it
doesn't even mention nph-scripts.
It is mentioned in the upgrading-to-1.3 documentation that one reason
for this change was to be able to support HTTP/1.1, encryption, and
chunking, even with nph-scripts. (Presumably chunking is supported to
enable persistent connections.)
So you might think it would fix the headers. You'd be wrong, though;
my ISP's "Stronghold/2.4.1 Apache/1.3.3 ..." web server doesn't insert
the ^M's.
--
<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
Tue Nov 02 1999
6 days until the Internet stock bubble bursts on Monday, 1999-11-08.
<URL:http://www.pobox.com/~kragen/bubble.html>
------------------------------
Date: 6 Nov 1999 21:59:00 -0000
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: CGI FAQ discussion, was Re: Problem with perl and MSIE5
Message-Id: <8028b4$bp8$1@gellyfish.btinternet.com>
On Sat, 6 Nov 1999 14:57:06 +0100 Alan J. Flavell wrote:
>
> [corrected posting with Supersedes header - sorry]
>
> On Fri, 5 Nov 1999, David Cassell wrote:
>
>> See? You do need to get these FAQs corrected.
>
> OK, so I've opened my big mouth, I suppose I'd better put my cards on
> the table.
>
<snip remainder>
I dont think there is anything there that I could disagree with, however
one thing occurs to me - if we do advocate the paring down of this entry
in the FAQ to be basically 'use CGI.pm or look elsewhere' we ought to be
certain that there is an elsewhere to which they can be redirected - most
of *us* are not unhappy about looking at RFCs or other technical
specifications to derive information that can be applied in practice but
this could be too much to ask of the usual posters who ask about these
things in this group and would be directed to these materials.
I'm not so sure that the CGI faq covers this in as much detail as you
have layed out here - perhaps some text based on yours could be put in
that ? Indeed isnt there a CGI autofaq somewhere now into which this
could be inserted.
/J\
--
Jonathan Stowe <jns@gellyfish.com>
<http://www.gellyfish.com>
Hastings: <URL:http://dmoz.org/Regional/UK/England/East_Sussex/Hastings>
------------------------------
Date: Sun, 7 Nov 1999 01:20:24 +0100
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: CGI FAQ discussion, was Re: Problem with perl and MSIE5
Message-Id: <Pine.HPP.3.95a.991107011745.19149A-100000@hpplus01.cern.ch>
On Sat, 6 Nov 1999, Kragen Sitaker wrote:
> >tolerant of other conventions), and so it would seem advisable to use
> >binary output mode, and to represent newlines with "\015\012" on all
> >platforms in this situation, to assure proper portability.
>
> Apache 1.3's FAQ claims that (a) prior to 1.3, you needed to use
> nph-scripts to get unbuffered output, and (b) "today, the only
> difference between nph-scripts and normal scripts is that nph-scripts
> require the full headers to be sent".
[...]
> So you might think it would fix the headers. You'd be wrong, though;
> my ISP's "Stronghold/2.4.1 Apache/1.3.3 ..." web server doesn't insert
> the ^M's.
I think you're confirming the conclusion that an NPH script would be
well advised to write \015\012 explicitly, yes?
(Just to make sure I've got your message correctly, thanks).
------------------------------
Date: 06 Nov 1999 19:44:08 -0500
From: Uri Guttman <uri@sysarch.com>
Subject: Re: CGI FAQ discussion, was Re: Problem with perl and MSIE5
Message-Id: <x7u2mz167b.fsf@home.sysarch.com>
>>>>> "KS" == Kragen Sitaker <kragen@dnaco.net> writes:
KS> Apache 1.3's FAQ claims that (a) prior to 1.3, you needed to use
KS> nph-scripts to get unbuffered output, and (b) "today, the only
KS> difference between nph-scripts and normal scripts is that nph-scripts
KS> require the full headers to be sent".
KS> You'd think the documentation for mod_cgi would explain further, but it
KS> doesn't even mention nph-scripts.
and that seems to be wrong too. i just got busted trying to use
CGI::Push and apache. following the apache docs, i used my regular name
for the script and apached barfed with header parsing errors. tracking
down the code, it was checking for : in every header and CGI was
printing out the first line as HTTP/1.0 OK 200. no colon, barf! i found
a wacky fix by setting the env SERVER_PROTOCOL to 'PROTO:' (anything
with a : would do) and it prints that at the beginning of the protocol
line. the real fix, of course, is to prepend nph- to the script name. so
apache 1.3 docs lie here, nph scripts are different than regular cgi
scripts. regular ones get their headers parsed, nph do not.
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
------------------------------
Date: Sun, 07 Nov 1999 02:05:46 GMT
From: kragen@dnaco.net (Kragen Sitaker)
Subject: Re: CGI FAQ discussion, was Re: Problem with perl and MSIE5
Message-Id: <_75V3.49769$23.1894685@typ11.nn.bcandid.com>
In article <x7u2mz167b.fsf@home.sysarch.com>,
Uri Guttman <uri@sysarch.com> wrote:
>and that seems to be wrong too. i just got busted trying to use
>CGI::Push and apache. following the apache docs, i used my regular name
>for the script and apached barfed with header parsing errors. tracking
>down the code, it was checking for : in every header and CGI was
>printing out the first line as HTTP/1.0 OK 200. no colon, barf! i found
>a wacky fix by setting the env SERVER_PROTOCOL to 'PROTO:' (anything
>with a : would do) and it prints that at the beginning of the protocol
>line. the real fix, of course, is to prepend nph- to the script name. so
>apache 1.3 docs lie here, nph scripts are different than regular cgi
>scripts. regular ones get their headers parsed, nph do not.
Actually, that's what the docs I quoted say. :) Although I didn't
understand them when I read them the first time, and I thought they
meant the same thing you did. The way non-nph-scripts are now like
nph-scripts is that their output is not *buffered*.
Alan: yes, I was confirming that you are correct. My apologies for the
stream-of-consciousness style of my writing; at first I thought you
weren't, then I tested and found out you were, but I didn't go back and
change the earlier text.
--
<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
Tue Nov 02 1999
6 days until the Internet stock bubble bursts on Monday, 1999-11-08.
<URL:http://www.pobox.com/~kragen/bubble.html>
------------------------------
Date: Sun, 7 Nov 1999 21:05:33 +0100
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: CGI FAQ discussion, was Re: Problem with perl and MSIE5
Message-Id: <Pine.HPP.3.95a.991107205438.28368E-100000@hpplus01.cern.ch>
On Sun, 7 Nov 1999, Kragen Sitaker wrote:
> Actually, that's what the docs I quoted say. :) Although I didn't
> understand them when I read them the first time, and I thought they
> meant the same thing you did. The way non-nph-scripts are now like
> nph-scripts is that their output is not *buffered*.
Right. It's still the case that NPH scripts must send out a complete
and accurate HTTP response, beginning with the HTTP/1.x nnn rhubarb
status response, and followed by a proper set of HTTP headers (that IS
how NPH scripts are defined, after all), whereas non-NPH scripts are not
allowed to send the HTTP/1.x thing: if _they_ need to influence the
status code, for example to return 301 permanent redirection instead of
302 temporary redirection, they must send out the _CGI_ "Status:" header
(and it's the job of the server to create a full and consistent HTTP
transaction based on that).
[Didactic mode on, for anyone who cares to listen]
Unlike the CGI "Status:" response, there is no HTTP "Status:" header;
furthermore, the CGI "Location:" response comes in two different
flavours, one of which MUST be turned into an HTTP "Location:"
transaction (external redirection), while the other MUST be handled
internally by the server (sometimes known as an internal redirection).
This is why I always make a fuss about keeping in mind a proper
distinction between CGI headers and HTTP headers, in spite of the
similarity.
[mode off]
> Alan: yes, I was confirming that you are correct.
Thanks...
> My apologies for the
> stream-of-consciousness style of my writing;
Not at all. Thanks for the input.
------------------------------
Date: Mon, 08 Nov 1999 10:54:56 -0800
From: voltemand@earthlink.net
Subject: Re: CGI FAQ discussion, was Re: Problem with perl and MSIE5
Message-Id: <38271C7F.B41D0BBE@earthlink.net>
Uri Guttman wrote:
> >>>>> "A" == Abigail <abigail@delanet.com> writes:
>
> [snip intelligent discussion]
>
> there still has to be created a perl SDK with many of the more popular
> and useful modules already built with perl for many common platforms.
> that would make creating turnkey systems with perl that much easier.
>
Some of us newbies who haven't got our linux boxes up yet and are running on ,
say, Macs would dearly appreciate something like that. Kind of hard to
experiment
with alot of this stuff without having one's own apache, etc.
Cheers.
-Michael
voltemand@earthlink.net
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
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.
| NOTE: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
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 V9 Issue 1294
**************************************
