Re: [?] Same Named Modules, Different Paths
Sam Tregar wrote: On Sun, 3 Feb 2002, Stas Bekman wrote: I think the best solution is to run your staging server on a different port and use a front-end proxy to rewrite to the right server based on the Host: name. Alternatively put 2 NICs with 2 IPs, that will work if you don't hardcode the server name in your code/html. Or 1 NIC with 2 IPs if your OS supports it (Linux does). yup, thanks :0) BTW, mod_perl 2.0 solves this problem. How? Is the one global namespace per server changed in 2.0 perhaps? in mp-2.0 each vhost can have its own pool of perl interpreters, but please read the whole thing here: http://www.apache.org/~dougm/modperl_2.0.html#mod_perl%20and%20threaded%20mpms soon these docs will appear on perl.apache.org _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: modperl growth
Paul DuBois [EMAIL PROTECTED] writes: Mac OS X includes Apache, and mod_perl works there, too. That's another group of potential new mod_perl-ized servers. I think all the recent RedHats come with mod_perl as a DSO by default. -- Dave Hodgkinson, Wizard for Hire http://www.davehodgkinson.com Editor-in-chief, The Highway Star http://www.deep-purple.com Interim Technical Director, Web Architecture Consultant for hire
Re: MacOSX Requests and Cookies
On Fri, Feb 01, 2002 at 10:39:02PM -0500, Joe Schaefer wrote:
...
Great - thanks a ton!
Not so great. I'm half asleep. You need to do patch -r or, apply the
forward patch included below...
rick
--- http_main.c~ Mon Jan 28 04:07:46 2002
+++ http_main.cFri Feb 1 19:22:51 2002
@@ -7805,5 +7805,12 @@
{
return ApacheRequest_new(r);
}
+/*RAF*/
+#include apache_cookie.h
+ApacheCookie *suck_in_apcookie(request_rec *r);
+ApacheCookie *suck_in_apcookie(request_rec *r)
+{
+return ApacheCookie_new(r);
+}
#endif /* USE_APREQ */
Re: CGI Upload/download question
Medi Montaseri wrote: Can I somehow influence this behavior such that the user will indeed see something like MyFile.txt.returned or MyFile.txt.processed in the dialog box. Add a Content-Disposition header like this: Content-Disposition: attachment; filename=MyFile.txt.returned I don't remember for sure, but I think a Content-Length header might help browsers evaluate the time remaining for the download. By the way, the reason for the crazy MIME type, is to prevent the browser to render it. I'm trying to achive a complete upload-process-download. Perhaps there is an standard MIME type that I should use. There is a standard type for that function, application/octet-stream. Of course, whatever you set the Content-Type header to, Internet Explorer could cheerfully ignore it if the extension is associated on the client machine, but that's not your problem anymore I guess... ;-) -- Pierre Phaneuf
hi, help needed...
Hi, i got apache about 3 weeks ago, and like to modify it the way i like. Iwas on this website, which i believe is yours. How can i make the same thing on my apache (win32) 1.3.22 http://www.xorgate.com/Apache/OpenIndex/demo/ what exactly do i need to type in httpd.conf ? the explanation on the website is too cofusing, please help me out. If it is possible i would like to get the exact code to insert into httpd.conf code Best regards, Peter James
RE: [OT] email attachments - Win32 email reader to replace OE
:: I think, as somebody said, that migrating to Outlook instead :: of Outlook Express might be something (though you won't be :: free from worms, virii, etc.). There is a patch available from Microsoft which prohibits the opening of certain types of attachments. This makes Outlook (not Outlook Express) pretty secure. In any case, who opens attachments these days anyway? It's all down to common sense surely. Use a good virus checker, keep it up to date (I update my signature files daily), don't open unexpected attachments and, if you use Outlook or Outlook Express, turn off the Auto Preview feature - then you're pretty safe, regardless of the email client you're using. Jonathan M. Hollin - WYPUG Co-ordinator West Yorkshire Perl User Group http://wypug.pm.org/
Re: MacOSX Requests and Cookies
John Siracusa [EMAIL PROTECTED] writes: Well, I can confirm that it still doesn't work for me... :-/ Is everyone using Perl 5.6.1 here? Because somehow some of the files I downloaded had the string perl500503 embedded in them. Even after search/replacing all that, I ended up with an httpd that pukes with the same old symbol conflicts when I try to start it. Don't try to use the modperl tree that's in the apache tarball- it was left in there by mistake (I didn't realize make distclean won't remove modperl from the apache source tree). You need the modperl source to compile everything from scratch, starting with modperl. When you're testing Apache::Cookie and Apache::Request, be sure you're not trying to load the old versions of these packages. Sorry for the confusion. -- Joe Schaefer
Re: hi, help needed...
Hi there, On Sat, 2 Feb 2002, unknown wrote: I was on this website, which i believe is yours. How can i make the same thing on my apache (win32) 1.3.22 http://www.xorgate.com/Apache/OpenIndex/demo/ I'm not sure I understand the question. If you want a demonstration of Apache running on your computer then there are lots of ways to go about it. If you want to copy and use or publish a Web site you should perhaps start by ascertaining if doing that would (a) not infringe any copyright (b) not offend anyone and (c) not be outside the capabilities of your hardware, assuming that (d) it would be of some use to you when it's done. If you want to use a particular feature or module then you first need to understand how the Web works (with particular reference to the DNS, HTTP and HTML), how web servers and browsers fit into that, how to build and install Apache and how to configure it, how to populate its data structures and how to generate suitable data. When you have done all that you can start Apache. Some of it might sound a bit heavy and even though I have excluded mod_perl itself from that little lot there is I'm afraid still far too much to get under your belt at one sitting. If you have any other life at all, budget a few months from a standing start to get a reasonable grasp of it. what exactly do i need to type in httpd.conf ? the explanation on the website is too cofusing, please help me out. If it is possible i would like to get the exact code to insert into httpd.conf It doesn't work that way (and people here on the mod_perl list like you to think for yourself a little:). This list is specifically about mod_perl issues. It may be that you need a mod_perl Apache to be able to do what you want to do and it may not. I'm not clear about that. If you have not yet successfully installed an Apache of any sort then I think you should do that first. There is an excellent book called Professional Apache ISBN-1-86100-302-1 available in many good book stores (including mine:) which will lead you through the Apache installation and configuration processes. If you find you do need a mod_perl Apache come back here, after you have read a few good books on Perl, plus the Guide (I think maybe two or three times:). http:/perl.apache.org/guide and the Eagle book Writing Apache Modules with Perl and C, ISBN 1-56592-567-X you will then be better placed to ask a question which someone here can answer. 73, Ged.
Re: modperl growth
At 11:02 + 2/3/02, Dave Hodgkinson wrote: Paul DuBois [EMAIL PROTECTED] writes: Mac OS X includes Apache, and mod_perl works there, too. That's another group of potential new mod_perl-ized servers. I think all the recent RedHats come with mod_perl as a DSO by default. I just looked on a RH 7.2 machine. It has the AddModule line in the default httpd.conf, but no mod_perl.so in the modules directory.
Re: modperl growth
Paul DuBois wrote: I think all the recent RedHats come with mod_perl as a DSO by default. I just looked on a RH 7.2 machine. It has the AddModule line in the default httpd.conf, but no mod_perl.so in the modules directory. I think the DSO in a separate mod_perl RPM package. -- Pierre Phaneuf
Re: MacOSX Requests and Cookies
On 2/3/02 10:23 AM, Joe Schaefer wrote: John Siracusa [EMAIL PROTECTED] writes: Well, I can confirm that it still doesn't work for me... :-/ Is everyone using Perl 5.6.1 here? Because somehow some of the files I downloaded had the string perl500503 embedded in them. Even after search/replacing all that, I ended up with an httpd that pukes with the same old symbol conflicts when I try to start it. Don't try to use the modperl tree that's in the apache tarball- it was left in there by mistake (I didn't realize make distclean won't remove modperl from the apache source tree). You need the modperl source to compile everything from scratch, starting with modperl. When you're testing Apache::Cookie and Apache::Request, be sure you're not trying to load the old versions of these packages. Okay, I tried it again, from the very beginning. I made a shell script to automate it. The shell script is attached. The result of running it appears in full below. The upshot is the final bit: --- dyld: bin/httpd Undefined symbols: _ApacheRequest___parse _ApacheRequest_expires _ApacheRequest_new _ApacheRequest_script_name _ApacheRequest_tmpfile _ApacheUpload_find _ap_null_cleanup _ap_pcalloc _ap_register_cleanup _ap_table_add _ap_table_get _ap_table_set _ap_table_unset _hvrv2table _mod_perl_tie_table _perl_request_rec _sv2request_rec --- So...what am I doing wrong? -John --- # ./mpapache.sh Sun Feb 3 14:12:45 EST 2002 Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=darwin, osvers=1.4, archname=darwin uname='darwin localhost 1.4 darwin kernel version 1.4: sun sep 9 15:39:59 pdt 2001; root:xnuxnu-201.obj~1release_ppc power macintosh powerpc ' config_args='-des -Dfirstmakefile=GNUmakefile -Dldflags=-flat_namespace' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cc', ccflags ='-pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing -I/usr/local/include', optimize='-O3', cppflags='-pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='Apple devkit-based CPP 6.0', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags ='-flat_namespace -L/usr/local/lib' libpth=/usr/local/lib /usr/lib libs=-lm -lc perllibs=-lm -lc libc=/System/Library/Frameworks/System.framework/System, so=dylib, useshrplib=true, libperl=libperl.dylib Dynamic Linking: dlsrc=dl_dyld.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-flat_namespace -bundle -undefined suppress -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under darwin Compiled at 01/26/02 17:02:40 %ENV: PERL_READLINE_NOWARN= @INC: /System/Library/Perl/darwin /System/Library/Perl /Library/Perl/darwin /Library/Perl /Library/Perl /Network/Library/Perl/darwin /Network/Library/Perl /Network/Library/Perl . Will configure via APACI Configure mod_perl with ../apache_1.3.23/src ? [y] y Shall I build httpd in ../apache_1.3.23/src for you? [y] n (cd ../apache_1.3.23/src ./Configure -file Configuration)cp apaci/Makefile.libdir ../apache_1.3.23/src/modules/perl/Makefile.libdir cp apaci/Makefile.tmpl ../apache_1.3.23/src/modules/perl/Makefile.tmpl cp apaci/README ../apache_1.3.23/src/modules/perl/README cp apaci/configure ../apache_1.3.23/src/modules/perl/configure cp apaci/libperl.module ../apache_1.3.23/src/modules/perl/libperl.module cp apaci/mod_perl.config.sh ../apache_1.3.23/src/modules/perl/mod_perl.config.sh cp apaci/load_modules.pl ../apache_1.3.23/src/modules/perl/load_modules.pl cp apaci/find_source ../apache_1.3.23/src/modules/perl/find_source cp apaci/apxs_cflags ../apache_1.3.23/src/modules/perl/apxs_cflags cp apaci/perl_config ../apache_1.3.23/src/modules/perl/perl_config cp apaci/mod_perl.exp ../apache_1.3.23/src/modules/perl/mod_perl.exp PerlDispatchHandler.enabled PerlChildInitHandlerenabled PerlChildExitHandlerenabled PerlPostReadRequestHandler..enabled PerlTransHandlerenabled PerlHeaderParserHandler.enabled PerlAccessHandler...enabled PerlAuthenHandler...enabled PerlAuthzHandlerenabled PerlTypeHandler.enabled PerlFixupHandlerenabled PerlHandler.enabled PerlLogHandler..enabled PerlInitHandler.enabled PerlCleanupHandler..enabled
[ANNOUNCE] Apache::UploadMeter-0.21
The URL http://prdownloads.sourceforge.net/apache-umeter/Apache-UploadMeter-0.21.tar.gz has entered CPAN as file: $CPAN/authors/id/I/IS/ISAAC/Apache-UploadMeter-0.21.tar.gz size: 7293 bytes md5: c2b830b7a6204d40050946c5d84c9583 Also available on SourceForge (see above URL). SourceForge project homepage http://sourceforge.net/projects/apache-umeter Issac Release Notes ChangeLog: *Notes:* The following Perl libraries are now required: Format::Number Format::Date I hope to remove these dependancies as soon as I can get formatting done in XSL *Changes:* UploadMeter_port.patch: Adds the port number to the generated Refresh URL UploadMeter_finished.patch: Stops the Meter from Refreshing endlessly when the upload is complete UploadMeter_starttime.patch: Adds the time the upload started to the output to allow upload rate calculations (Patches submitted by Cees Hek ) ### XSLT + XML Patch submitted by Cees Hek Started migrating internal calculations to XSLT Updated Schema (switch from DTD to xsd) ### 0.21 : Feb 3, 2002 - Prebundled basic skin on sourceforge. Migrate from DTD to schema. Time/Date formatting currently server-side.
Re: [OT] email attachments - Win32 email reader to replace OE
Some kind of off-the-cuff reviews from a friend you might find interesting. Note the criterion: $20 and HTML on/off I am using Vivian as my main client, but it is lacking in a few functions that need work. It is the ONLY client I have found so far that doesn't support HTML and it has a really nice headers view of the mail on the server that allows you to choose download, download/delete, delete before you POP it. It doesn't routinely check your mail for you though. I registered (It's freeware) and sent the guy a few bucks to encourage his development. So far, I'm putting my money on POCO as the closest competitor to OE (if you bar Messenger (I did for HTML reasons)). I have two more to look at, but so far, nothing promising. I started with two criterion money (had to be free or less than $20) and be able to turn off HTML/helper applications (no virus carriers). Mahogany might be promising when the windows version gets out of beta. So far, this is what I have done : Outlook Express, Messenger, Pegasus, Iris, PMMail, Mail Warrior, Vivian, Hmmm, roll your own with Sylpheed? And what he had to say about The Bat: Yep, It was very complex. I've heard good and bad talk about it. The HTML features can't be controlled and the cost made it one of my no choices. I am currently on one of my finds and rather liking it. Take a look at QuickMail Pro. It was written for the MAC, but is rather nice for Doze. Pricey at $40, but maybe I need to look at some of these... (my Doze crashed earlier and I was forced to send before I included all of the different mail clients I have tried. Quite a few. If I could have gotten it to work correctly, I'd have stayed with Kaufman Mail Warrior (my first). I hope that this points those looking in some directions at some of the low-cost alternatives out there. Mike808/ -- perl -le $_='7284254074:0930970:H4012816';tr[0-][ BOPEN!SMUT];print
Make test issue with the URI module
I am trying to install the latest version of Mod_perl (version 1.26) with Apache 1.3.23 on RedHat 7.2. When I tried the make test from the mod_perl installation I had an error saying that the module URI couldn't be found. I then downloaded and installed the URI module from cpan.org: URI-1.18 and now I get the following error: /usr/bin/perl t/TEST 0 Can't locate object method new via package URI::URL at ../blib/lib/Apache/te st.pm line 252. Anything I am doing wrong? Thanks for you help, Pierre
Re: MacOSX Requests and Cookies
Hi there, On Sun, 3 Feb 2002, John Siracusa wrote: Okay, I tried it again, from the very beginning. [snip] So...what am I doing wrong? Well this doesn't look good... [snip] /usr/bin/ld: warning -L: directory name (/usr/local/lib) does not exist [snip] ...nor does this. [snip] Checking if your kit is complete... Warning: the following files are missing in your kit: Makefile.in c/Makefile.in configure Please inform the author. but I never tried to do what you're trying to do. 73, Ged.
Odd mod_perl and LimitRequestBody problem
We just experienced an odd problem and were wondering if anyone has encountered this before. We recently set the apache LimitRequestBody parameter to 1000 (10M) and all was working fine until a recent restart. We started getting errors in the logs whenever there was a file upload field in the form, even if no file was selected. [Sun Feb 3 21:01:23 2002] [error] [client 127.0.0.1] [libapreq] could not create/open temp file No other changes had been made, and these started occuring immediately after we did a apachectl stop/start cycle. We restarted the server 3 times, each time the same problem occured. On the 4th restart, everything started working fine again, even though no other changes had been made. Has anyone ever had a similar experience to this? It's just a bit disturbing... Apache: 1.3.22 mod_perl: 1.26 libapreq: 0.33 Rob
mod_proxy bug in Apache 1.3.23
Since a lot of folks end up using mod_proxy in a dual-server setup, I thought I'd let people know of this bug (which I discovered after several hours of pounding my head against a brick wall). The version of mod_proxy shipped with Apache 1.3.23 will silently drop multiple Set-Cookie headers, leaving only the last one. So if your mod_perl app (on a backend server) tries to set multiple cookies, only the last one makes it through. This will break your app, for obvious reasons. Its already been reported in the Apache bug DB: http://bugs.apache.org/index.cgi/full/9595 http://bugs.apache.org/index.cgi/full/9655 -dave /*== www.urth.org we await the New Sun ==*/
Re: Solved - Odd mod_perl and LimitRequestBody problem
My fault, better be more careful when playing with environment vars. libapreq uses tempnam(3), which uses the environment var TMPDIR when creating temporary file names. Two of us were working on the server, one had it set, the other didn't. That's why one person restarting the server continued to have the problems, while when the other person restarted the server, it suddenly fixed itself. Rob - Original Message - From: Rob Mueller (fastmail) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 04, 2002 4:19 PM Subject: Odd mod_perl and LimitRequestBody problem We just experienced an odd problem and were wondering if anyone has encountered this before. We recently set the apache LimitRequestBody parameter to 1000 (10M) and all was working fine until a recent restart. We started getting errors in the logs whenever there was a file upload field in the form, even if no file was selected. [Sun Feb 3 21:01:23 2002] [error] [client 127.0.0.1] [libapreq] could not create/open temp file No other changes had been made, and these started occuring immediately after we did a apachectl stop/start cycle. We restarted the server 3 times, each time the same problem occured. On the 4th restart, everything started working fine again, even though no other changes had been made. Has anyone ever had a similar experience to this? It's just a bit disturbing... Apache: 1.3.22 mod_perl: 1.26 libapreq: 0.33 Rob
