Re: Apache::File correction
Rob Nagler <[EMAIL PROTECTED]> writes:
> > undef $/; # enable "slurp" mode
>
> I think the "local" is pretty important, especially in mod_perl:
>
> local $/;
>
> This has the same effect (the "undef" is unnecessary). It's also a
> good idea to enclose the code in a subroutine with error checking:
>
> sub read_file {
> my($file) = @_;
> open(FH, "< $file") || die("error opening $file: $!");
> local($/);
> my($content) = ;
> close(FH) && defined($content) || die("error reading $file: $!");
> return \$content;
> }
A similiar idiom that I saw recently:
sub file_contents {
my $fn = shift;
open(FOO, $fn)
or die "file_contents: open($fn): $!\n";
my $stuff;
read FOO, $stuff, -s FOO;
close(FOO);
return $stuff;
}
Take your pick as to which one is clearer...
-Dom
--
| Semantico: creators of major online resources |
| URL: http://www.semantico.com/ |
| Tel: +44 (1273) 72 |
| Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |
Re: Apache::File correction
> undef $/; # enable "slurp" mode
I think the "local" is pretty important, especially in mod_perl:
local $/;
This has the same effect (the "undef" is unnecessary). It's also a
good idea to enclose the code in a subroutine with error checking:
sub read_file {
my($file) = @_;
open(FH, "< $file") || die("error opening $file: $!");
local($/);
my($content) = ;
close(FH) && defined($content) || die("error reading $file: $!");
return \$content;
}
Rob
Re: Apache::File correction
Martin Haase-Thomas wrote: > > [snip] Secondly I wonder whether "local $/ = undef" > will have any effect. But I've never tried overriding Perl's predefined > variables. > > regards Dear Martin, this is the well-known file-slurp mode. E.g.: undef $/; # enable "slurp" mode $_ = ; # whole file now here s/\n[ \t]+/ /g; Look for "slurp" in your perl docs. Ernest -- * * VIRTUALITAS Inc. * * ** * * European Consultant Office * http://www.virtualitas.net * * Internationales Handelszentrum * contact:Ernest Lergon * * Friedrichstraße 95 *mailto:[EMAIL PROTECTED] * * 10117 Berlin / Germany * ums:+49180528132130266 * * PGP-Key http://www.virtualitas.net/Ernest_Lergon.asc
Re: Apache::File correction
Hi,
maybe I don't exactly understand what you mean. To me it looks like you
want to direct a stream into a file. Perhaps IO::Handle or IO::Scalar
will provide what you need. Secondly I wonder whether "local $/ = undef"
will have any effect. But I've never tried overriding Perl's predefined
variables.
regards
Martin
Rasoul Hajikhani wrote:
>Folks,
>The Apache::File man pages indicate that
>
>($name,$fh) = Apache::File->tmpfile;
>
>returns a fh ready to write to. So far so good.
>
>In case of wanting to read from it, here is what I do:
>
># Is this necessary?
>$fh->close() or die "Could not close $name: $!\n";
>
>$fh->open("<$name");
>local $/= undef;
>$output = <$fh>;
>warn "$output\n";
>$fh->close() or die "Could not close $name: $!\n";
>
>But $output is empty on each request. Is there an error somewhere that I
>am not seeing? I appreciate all comments.responses.
>Thanks in advance
>-r
>
--
http://www.meome.de
---
Martin Haase-Thomas | Tel.: 030 43730-558
meOme AG| Fax.: 030 43730-555
Software Development| [EMAIL PROTECTED]
---
Re: Apache::File correction
Robert Landrum wrote:
>
> At 1:44 PM -0700 4/10/02, Rasoul Hajikhani wrote:
> >Folks,
> >The Apache::File man pages indicate that
> >
> >($name,$fh) = Apache::File->tmpfile;
> >
> >returns a fh ready to write to. So far so good.
> >
> >In case of wanting to read from it, here is what I do:
> >
> ># Is this necessary?
> >$fh->close() or die "Could not close $name: $!\n";
> >
> >$fh->open("<$name");
> >local $/= undef;
> >$output = <$fh>;
> >warn "$output\n";
> >$fh->close() or die "Could not close $name: $!\n";
>
> To me it appears that you have not written anything to your tmp
> file... Which would explain the empty $output.
>
gpg writes to that file.
> Usually temp file creators open in read/write mode.
>
> So if you say something like
>
> ($name,$fh) = Apache::File->tmpfile;
>
> print $fh "Hello World";
>
> seek($fh,0,0);
>
> my $line = <$fh>;
>
> print $line;
>
> It should print "Hello World";
>
> Rob
>
> --
> When I used a Mac, they laughed because I had no command prompt. When
> I used Linux, they laughed because I had no GUI.
Re: Apache::File correction
At 1:44 PM -0700 4/10/02, Rasoul Hajikhani wrote:
>Folks,
>The Apache::File man pages indicate that
>
>($name,$fh) = Apache::File->tmpfile;
>
>returns a fh ready to write to. So far so good.
>
>In case of wanting to read from it, here is what I do:
>
># Is this necessary?
>$fh->close() or die "Could not close $name: $!\n";
>
>$fh->open("<$name");
>local $/= undef;
>$output = <$fh>;
>warn "$output\n";
>$fh->close() or die "Could not close $name: $!\n";
To me it appears that you have not written anything to your tmp
file... Which would explain the empty $output.
Usually temp file creators open in read/write mode.
So if you say something like
($name,$fh) = Apache::File->tmpfile;
print $fh "Hello World";
seek($fh,0,0);
my $line = <$fh>;
print $line;
It should print "Hello World";
Rob
--
When I used a Mac, they laughed because I had no command prompt. When
I used Linux, they laughed because I had no GUI.
Apache::File correction
Folks,
The Apache::File man pages indicate that
($name,$fh) = Apache::File->tmpfile;
returns a fh ready to write to. So far so good.
In case of wanting to read from it, here is what I do:
# Is this necessary?
$fh->close() or die "Could not close $name: $!\n";
$fh->open("<$name");
local $/= undef;
$output = <$fh>;
warn "$output\n";
$fh->close() or die "Could not close $name: $!\n";
But $output is empty on each request. Is there an error somewhere that I
am not seeing? I appreciate all comments.responses.
Thanks in advance
-r
Apache::File
Folks,
The Apache::File man pages indicate that
($name,$fh) = Apache::File->tmpfile;
returns a fh ready to write to. So far so good.
In case of wanting to read from it, here is what I do:
# Is this necessary?
$fh->close() or die "Could not close $name: $!\n";
$opfh->open("<$name");
local $/= undef;
$output = <$opfh>;
warn "$output\n";
$opfh->close() or die "Could not close $name: $!\n";
But $output is empty on each request. Is there an error somewhere that I
am not seeing? I appreciate all comments.responses.
Thanks in advance
-r
Re: [Q] Apache::File->new
Ok, these are the lines from httpd.conf. The default-handler in /app/jsp
is inserted because I hope that i'll get resin taking over the request in
case the .pm declines. (hope this is right)
RewriteRule ^(.*)/(intl|de)/(.*) $1/jsp/$3 [QSA]
RewriteRule ^/$ /app/jap/home.jsp/23323.html [NS,R,L]
RewriteMap shortnames txt:/etc/apache/shortnames.txt
RewriteCond %{REQUEST_FILENAME} ^/[a-zA-Z0-9]+/?$
RewriteRule /([a-zA-Z0-9]+)/? ${shortnames:$1} [T=text/html,R,L,NS]
RewriteRule .*/favicon\.ico$ /statics/favicon.ico [PT]
RewriteRule ^/s\.gif$ /statics/pics/space.gif [PT]
RewriteRule ^/robots.txt$ /statics/robots.txt [NS,PT]
#pictures vom cms-server
RewriteRule ^/pictures/(.*) http://cms-dev/pictures/$1
# This one has to be the last in row:
RewriteRule ^(.*)_jsp(.*)$ $1.jsp$2 [QSA]
SetHandler default-handler
# serve static files:
SetHandler perl-script
PerlHandler Apache::StaticServer
Some lines from the .pm. Its purposeis to serve a static file instead of
the requested jsp. For instance, if I send a request for
something like "/app/jsp/category.jsp/23323" or "/app/jsp/category.jsp/23323.html"
the handler has to look after a file named
%{DOCUMENT_ROOT}/app/html/category_jsp/23323.html, and if it doesn't exist,
decline.
$catid = $r->path_info || "/23323"; # ancient rewrite rule
$fname = $r->filename;
$fname =~ s/.jsp$/_jsp/;
$fname =~ s:/jsp/:/html/:;
$fname .= $catid;
$fname .= ".html" unless $fname =~ /\.html$/; $r->log()->debug($fname."\n".$r->filename);
$fh = Apache::File->new($fname) || return DECLINED;
$r->header_out('Content-Length', -s $fname);
$r->update_mtime((stat $fname)[9]);
$r->send_http_header;
$r->send_fd($fh);
close $fh;
OK;
Here's a line from error_log which comes from the $r->log()->debug(...)
verse and says exactly what it has to:
[Tue Feb 12 15:03:55 2002] [debug] /usr/local/share/perl/5.6.1/ApacheStaticServer.pm(37):
[client 192.168.255.75] /home/disp05/app/html/category_jsp/67567.html
/home/disp05/app/jsp/category.jsp
If I send a request trhough a simple LWP client, here's what it says:
./client.pl http://disp05/app/jsp/category.jsp/67567
500 (Internal Server Error) unexpected EOF before status line seen
Client-Date: Tue, 12 Feb 2002 13:57:18 GMT
Ans this is what I find in my rewrite_log:
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(2) init rewrite engine with requested uri /app/jsp/category.jsp/67567
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '^(.*)/(intl|de)/(.*)' to uri '/app/jsp/category.jsp/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '^/$' to uri '/app/jsp/category.jsp/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '/([a-zA-Z0-9]+)/?' to uri '/app/jsp/category.jsp/67567'192.168.255.75
- - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(4) RewriteCond: input='/app/jsp/category.jsp/67567' pattern='^/[a-zA-Z0-9]+/?$'
=> not-matched
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '.*/favicon\.ico$' to uri '/app/jsp/category.jsp/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '^/s\.gif$' to uri '/app/jsp/category.jsp/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '^/robots.txt$' to uri '/app/jsp/category.jsp/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '^/pictures/(.*)' to uri '/app/jsp/category.jsp/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '^(.*)_jsp(.*)$' to uri '/app/jsp/category.jsp/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(1) pass through /app/jsp/category.jsp/67567
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b5494/subreq]
(2) init rewrite engine with requested uri /67567
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b5494/subreq]
(3) applying pattern '^(.*)/(intl|de)/(.*)' to uri '/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b5494/subreq]
(3) applying pattern '.*/favicon\.ico$' to uri '/67567'
192.168.255.75
Re: [Q] Apache::File->new
Martin Haase-Thomas wrote: > > Hi, > I searched in the book, I searched in the FAQs - no I ask u: > > Does Apache::File->new start a subrequest? no. it is merely a layer over Perl's file IO methods (Perl_do_open from what I can see). > There are some mystical lines > in my rewrite_log, which might come from there. that seems strange. maybe post the lines if they are causing you grief.. HTH --Geoff
[Q] Apache::File->new
Hi, I searched in the book, I searched in the FAQs - no I ask u: Does Apache::File->new start a subrequest? There are some mystical lines in my rewrite_log, which might come from there. Thanx a lot Martin
RE: Can't Locate Apache::File
did you build mod_perl with EVERYTHING=1 or PERL_FILE_API=1? HTH --Geoff > -Original Message- > From: David E. Wheeler [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 29, 2000 1:56 PM > To: [EMAIL PROTECTED] > Subject: Can't Locate Apache::File > > > Hi All, > > I've just installed the latest version of Lincoln Stein's Apache::MP3 > (nice job, Doc!), which offers support for caching MP3 ICY > info. It uses > Apache::File to do so. This the first time I've used Apache::File on > this server, but was still surprised to find that it failed to load: > > [Wed Aug 23 10:14:53 2000] [error] Can't locate loadable object for > module Apache::File in @INC (@INC contains: > /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5/5.00503 > /usr/lib/perl5/site_perl/5.005/i386-linux > /usr/lib/perl5/site_perl/5.005 > .. /usr/local/apache/ /usr/local/apache/lib/perl) at > /usr/lib/perl5/site_perl/5.005/i386-linux/mod_perl.pm line 65535 > > As near as I can tell, it is in fact there, and when I do > > % perl -le 'use Apache::File;' > > It seems to load just fine. The module lives in > /usr/lib/perl5/site_perl/5.005/i386-linux/Apache/File.pm > Anyone got any > idea why it can't find it? > > I'm running Apache 1.3.12 with mod_perl 1.24 compiled in on > RedHat Linux > 6.2. > > TIA! > > David >
Can't Locate Apache::File
Hi All, I've just installed the latest version of Lincoln Stein's Apache::MP3 (nice job, Doc!), which offers support for caching MP3 ICY info. It uses Apache::File to do so. This the first time I've used Apache::File on this server, but was still surprised to find that it failed to load: [Wed Aug 23 10:14:53 2000] [error] Can't locate loadable object for module Apache::File in @INC (@INC contains: /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5/5.00503 /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.005 . /usr/local/apache/ /usr/local/apache/lib/perl) at /usr/lib/perl5/site_perl/5.005/i386-linux/mod_perl.pm line 65535 As near as I can tell, it is in fact there, and when I do % perl -le 'use Apache::File;' It seems to load just fine. The module lives in /usr/lib/perl5/site_perl/5.005/i386-linux/Apache/File.pm Anyone got any idea why it can't find it? I'm running Apache 1.3.12 with mod_perl 1.24 compiled in on RedHat Linux 6.2. TIA! David
Re: passing Apache::File to XS code that expects FILE *?
On Thu, 18 May 2000, Vivek Khera wrote:
> > "DM" == Doug MacEachern <[EMAIL PROTECTED]> writes:
>
> DM> On Wed, 17 May 2000, Matt Sergeant wrote:
> >> Well, this may be true, but if you load IO::File before startup then it's
> >> not too big a deal...
>
> DM> but it still adds a great deal of bloat to the server. and it's oo
> DM> interface, while very slick, adds quite a bit of runtime overhead, turn
> DM> the sugar sour imo.
>
> In an embedded environment like mod_perl, then how do you suggest to
> deal with the dangling file handles problem? That is, I'm processing
> a file or two, and some error occurs. In a normal perl program, I'd
> exit or return out and then when the program terminates, it
> automagically closes all the files. In mod_perl, the auto-close
> doesn't happen until much later. With the OO interface, when the
> handle goes out of scope, such as a function call return, the file is
> implicitly closed.
>
> What other mechanism do you propose to handle this situation other
> than IO::File? I use it all the time myself.
in addition to stas' hints, even local *FH does the job, e.g.:
#/dev/null so strace output is more readable
open my $fh, ">/dev/null";
select $fh;
$| = 1;
{
print "enter";
local *FH;
open FH, $0;
print "leave"
}
print "done";
% strace ~/test/io.pl
write(3, "enter", 5)= 5
-> open("/home/dougm/test/io.pl", O_RDONLY) = 4
fstat(4, {st_mode=S_ISGID|S_ISVTX|0401, st_size=0, ...}) = 0
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
write(3, "leave", 5)= 5
-> close(4)= 0
write(3, "done", 4) = 4
Re: passing Apache::File to XS code that expects FILE *?
On Thu, 18 May 2000, Vivek Khera wrote:
> > "DM" == Doug MacEachern <[EMAIL PROTECTED]> writes:
>
> DM> On Wed, 17 May 2000, Matt Sergeant wrote:
> >> Well, this may be true, but if you load IO::File before startup then it's
> >> not too big a deal...
>
> DM> but it still adds a great deal of bloat to the server. and it's oo
> DM> interface, while very slick, adds quite a bit of runtime overhead, turn
> DM> the sugar sour imo.
>
> In an embedded environment like mod_perl, then how do you suggest to
> deal with the dangling file handles problem? That is, I'm processing
> a file or two, and some error occurs. In a normal perl program, I'd
> exit or return out and then when the program terminates, it
> automagically closes all the files. In mod_perl, the auto-close
> doesn't happen until much later. With the OO interface, when the
> handle goes out of scope, such as a function call return, the file is
> implicitly closed.
>
> What other mechanism do you propose to handle this situation other
> than IO::File? I use it all the time myself.
guide... guide... guide... :) (I'll keep you updated with the search
really soon now)
http://perl.apache.org/guide/porting.html#Filehandlers_and_locks_leakages
perl < 5.6
use Symbol;
{
my $fh = gensym;
open $fh,
}
perl5.6
{
open my $fh, ...
}
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: passing Apache::File to XS code that expects FILE *?
On Thu, 18 May 2000, Vivek Khera wrote: > > "DM" == Doug MacEachern <[EMAIL PROTECTED]> writes: > > DM> On Wed, 17 May 2000, Matt Sergeant wrote: > >> Well, this may be true, but if you load IO::File before startup then it's > >> not too big a deal... > > DM> but it still adds a great deal of bloat to the server. and it's oo > DM> interface, while very slick, adds quite a bit of runtime overhead, turn > DM> the sugar sour imo. > > In an embedded environment like mod_perl, then how do you suggest to > deal with the dangling file handles problem? That is, I'm processing > a file or two, and some error occurs. In a normal perl program, I'd > exit or return out and then when the program terminates, it > automagically closes all the files. In mod_perl, the auto-close > doesn't happen until much later. With the OO interface, when the > handle goes out of scope, such as a function call return, the file is > implicitly closed. > > What other mechanism do you propose to handle this situation other > than IO::File? I use it all the time myself. use Apache; use Fcntl qw/:DEFAULT :flock/; my $fh = Apache->gensym(); sysopen($fh, "file", O_RDONLY) || die "Can't open: $!"; flock($fh, LOCK_SH) || die "Can't lock: $!"; ... when $fh goes out of scope it's closed and unlocked. Also see the guide section on exception handling. -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: passing Apache::File to XS code that expects FILE *?
> "DM" == Doug MacEachern <[EMAIL PROTECTED]> writes: DM> On Wed, 17 May 2000, Matt Sergeant wrote: >> Well, this may be true, but if you load IO::File before startup then it's >> not too big a deal... DM> but it still adds a great deal of bloat to the server. and it's oo DM> interface, while very slick, adds quite a bit of runtime overhead, turn DM> the sugar sour imo. In an embedded environment like mod_perl, then how do you suggest to deal with the dangling file handles problem? That is, I'm processing a file or two, and some error occurs. In a normal perl program, I'd exit or return out and then when the program terminates, it automagically closes all the files. In mod_perl, the auto-close doesn't happen until much later. With the OO interface, when the handle goes out of scope, such as a function call return, the file is implicitly closed. What other mechanism do you propose to handle this situation other than IO::File? I use it all the time myself.
Re: passing Apache::File to XS code that expects FILE *?
On Wed, 17 May 2000, Matt Sergeant wrote: > Well, this may be true, but if you load IO::File before startup then it's > not too big a deal... but it still adds a great deal of bloat to the server. and it's oo interface, while very slick, adds quite a bit of runtime overhead, turn the sugar sour imo.
Re: passing Apache::File to XS code that expects FILE *?
On Wed, 17 May 2000, Jim Winstead wrote: > Is there some trick to passing an Apache::File to a function from > an XS module that expects a FILE *? so long as the xsub uses a FILE *, the typemap will take care of the magic. for example, Apache::send_fd() is an xsub that uses the FILE * typemap: use Apache::File (); my $r = shift; $r->send_http_header; my $tmp = Apache::File->tmpfile; print $tmp "hi"; seek $tmp, 0, 0; $r->send_fd($tmp);
Re: passing Apache::File to XS code that expects FILE *?
On Wed, 17 May 2000, Jim Winstead wrote: > On May 17, Matt Sergeant wrote: > > Or IO::File->new_tmpfile(); > > I'd rather not go there. > > http://marc.theaimsgroup.com/?l=apache-modperl&m=95454378223412&w=2 Well, this may be true, but if you load IO::File before startup then it's not too big a deal... Alternatively use File::Temp on CPAN, Apache->gensym(), and open()/sysopen(). -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: passing Apache::File to XS code that expects FILE *?
On May 17, Matt Sergeant wrote: > Or IO::File->new_tmpfile(); I'd rather not go there. http://marc.theaimsgroup.com/?l=apache-modperl&m=95454378223412&w=2 Jim
Re: passing Apache::File to XS code that expects FILE *?
On Wed, 17 May 2000, Jim Winstead wrote: > Is there some trick to passing an Apache::File to a function from > an XS module that expects a FILE *? > > There's too much perl magic going on in the Apache::File implementation > for me to see where I can just pull the FILE * out. > > (Its not strictly necessary that I do this, of course, it would just > be nice so I can use Apache::File->tmpfile(). Of course I can do the > same basic thing with POSIX::tmpnam().) Or IO::File->new_tmpfile(); -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
passing Apache::File to XS code that expects FILE *?
Is there some trick to passing an Apache::File to a function from an XS module that expects a FILE *? There's too much perl magic going on in the Apache::File implementation for me to see where I can just pull the FILE * out. (Its not strictly necessary that I do this, of course, it would just be nice so I can use Apache::File->tmpfile(). Of course I can do the same basic thing with POSIX::tmpnam().) Jim
Apache::File wierdness
I'm getting a very irritating problem. I upgraded apache/mod_perl recently : Apache/1.3.11 (Unix) PHP/3.0.14 mod_fastcgi/2.2.2 mod_perl/1.21 and I'm getting an irritating error now with my mod_perl code that uses Apache::File.. Can't locate loadable object for module Apache::File in @INC.. An strace of httpd reveals that it is earching for File.so or libFile.so, however, I don't think this file is supposed to exist. What would cause it to be searched for? Any help would be appreciated. Thanks, Reza p.s. please CC me as I'm not on the list.. ([EMAIL PROTECTED])
strange: pdf page is loaded twice with Apache::File
Hi, I have a strange problem with Apache::File : everytime a PDF is loaded (ie. a plugin is started in the browser) I see two requests for the same file. This happens with no other file types and not with direct pdf downloads. What I don't understand is why NS or MSIE send Pragma: no-cache in the request. What does this mean? The response explicitly sets $r->no_cache(0) Dirk
