Re: DProf on Mac OS X
On 7/26/03 2:01 AM, Ged Haywood wrote: Any way you can try it on a different OS, or even try a different Perl? And before Stas jumps on me *again* for saying that I have no evidence that 5.8.0 is the culprit in this case. It just smells fishy to me. :) My next stop is Linux on x86, but I'd really like to get it working on OS X if possible. -John
DProf on Mac OS X
Has anyone gotten this to work on OS X? From http://perl.apache.org/docs/1.0/guide/performance.html % setenv PERL5OPT -d:DProf % httpd -X -d `pwd` ... make some requests to the server here ... % kill `cat logs/httpd.pid` % unsetenv PERL5OPT % dprofpp I've used this profiling technique on other Unix-like OSes, so I think I'm doing it right. But on OS X, I get a tiny tmon.out file that never grows after the initial server startup. I don't see any error messages or log lines. When I try to use Apache::DProf, I get a bus error on any request: [Fri Jul 25 18:52:48 2003] [notice] child pid 3840 exit signal Bus error (10) My setup: apache 1.3.27, mod_perl 1.27 % uname -a Darwin derkins 6.6 Darwin Kernel Version 6.6: Thu May 1 21:48:54 PDT 2003; root:xnu/xnu-344.34.obj~1/RELEASE_PPC Power Macintosh powerpc % perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=darwin, osvers=6.0, archname=darwin uname='darwin derkins 6.0 darwin kernel version 6.0: sat jul 27 13:18:52 pdt 2002; root:xnuxnu-344.obj~1release_ppc power macintosh powerpc ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-pipe -fno-common -no-cpp-precomp -fno-strict-aliasing', optimize='-O3', cppflags='-no-cpp-precomp -pipe -fno-common -no-cpp-precomp -fno-strict-aliasing' ccversion='', gccversion='3.1 20020420 (prerelease)', 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, prototype=define Linker and Libraries: ld='cc', ldflags =' -flat_namespace -L/usr/local/lib' libpth=/usr/local/lib /usr/lib libs=-lgdbm -ldbm -lm -lc perllibs=-lm -lc libc=/usr/lib/libc.dylib, so=dylib, useshrplib=true, libperl=libperl.dylib gnulibc_version='' 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 Aug 24 2002 14:44:56 %ENV: PERL5DB=use Devel::DProf PERL5OPT=-d:DProf PERL_READLINE_NOWARN= @INC: /Library/Perl/darwin /Library/Perl /Library/Perl/darwin /Library/Perl /Library/Perl
Re: ANNOUNCE: Apache::Dynagzip 0.10
On 7/20/03 11:12 PM, Slava Bizyayev wrote: Your own content-type is supposed to be overwritten only in case of the use of PerlSetVar UseCGIHeadersFromScript Off in your configuration file. You might wish to comment this line in your configuration file when your script generates correct header line in accordance with CGI/1.0 and/or CGI/1.1. I don't have that line in my config. I'm setting the content type using $r-content_type() in my apache module. I'm not using CGI/registry scripts, and I'm not doing print Content-Type: ... anywhere. -John
Re: ANNOUNCE: Apache::Dynagzip 0.10
On 7/21/03 9:47 AM, John Siracusa wrote: On 7/20/03 11:12 PM, Slava Bizyayev wrote: Your own content-type is supposed to be overwritten only in case of the use of PerlSetVar UseCGIHeadersFromScript Off in your configuration file. You might wish to comment this line in your configuration file when your script generates correct header line in accordance with CGI/1.0 and/or CGI/1.1. I don't have that line in my config. I'm setting the content type using $r-content_type() in my apache module. I'm not using CGI/registry scripts, and I'm not doing print Content-Type: ... anywhere. ...and in case this reply wasn't clear, I'd like a way to tell Apache::Dynagzip to never set the outgoing content type header, no matter what. Anyone with an apache module in the filter chain who sets the outgoing content type header will need this feature. -John
Re: ANNOUNCE: Apache::Dynagzip 0.10
Why does Apache/Dynagzip.pm call $r-content_type('text/html') in
several places? My apache module earlier in the Apache::Filter chain
sets $r-content_type to something else, but it then gets overridden by
Dynagzip.pm. If I comment out all the calls to
$r-content_type('text/html') in Dynagzip.pm. I get the correct content
type. I'd like it if I could get this behavior without modifying
Dynagzip.pm...
-John
Re: the deprecation of Apache-request in mp2
On 3/24/03 7:08 PM, Stas Bekman wrote: In the future I can see someone extending Apache::Request to handle CGI.pm's HTML generation in C, so the two could be replace each other. I've always thought that HTML generation does not belong in CGI.pm, so I don't see duplicating that functionality in an extended $r as a useful goal. Better to separate the HTML stuff (preferably into HTML widget objects, IMO) from request parsing and response formulation and delivery. -John
Load balancers
(This may seem off topic for this list, but I'll try to bring it around before the end of the message :) We've been struggling with load balancers for a while now. My requirements are pretty simple. I have a handful of plain and mod_perl apache servers, some of which are identical and a few of which are the only ones that can perform unique functions. We want a load balancer that: * distributes requests to the server(s) that can handle them. I need to route to specific servers based on requested URL and perhaps headers and/or protocol type (SSL). * detects when a server is down and does not send request to that server. This process should be as transparent to the user as possible. * doesn't crash or lock up. We started with mod_backhand, but it frequently seemed to get confused, failing to send requests to some hosts that were perfectly able to service requests, and then locking up entirely when a back-end server became overloaded. I also found the diagnostics to be inaccurate and misleading (or at least poorly documented), and the documentation in general to be lacking. Next, we tried pound, which looked promising due to its simplicity. Unfortunately, it too seems to freak out at least once a day, filling its log with errors like this: @40003e1ef2461015ce34 warning: error read from 123.123.123.123: Success @40003e1ef24621631c8c warning: cannot read headers. got [] @40003e1ef2462163d424 warning: error read from 123.123.123.123: Success @40003e1ef2462902488c warning: cannot read headers. got [] @40003e1ef246290332ec warning: error read from 123.123.123.123: Success @40003e1ef246312225dc warning: cannot read headers. got [] @40003e1ef2463122be34 warning: error read from 123.123.123.123: Success @40003e1ef24706782a84 warning: cannot read headers. got [] @40003e1ef2470678bef4 warning: error read from 123.123.123.123: Success @40003e1ef247176094bc warning: cannot read headers. got [] We've been in contact with the author and have tried digging around in and/or patching the source code with no improvement so far. But meanwhile, we're still open to alternatives. Surprisingly, there don't seem to be many (software) options. (A hardware load balancer is not an option at his time, but I'll also take any suggestions in that area :) This brings me to the mod_perl angle. Has anyone ever tried using a slimmed down mod_perl server as a load balancer? Is this feasible? Making routing decisions is obviously the easy part when using mod_perl, but would those mod_perl apache process just be too big and too slow to proxy requests efficiently? And how would they deal with detecting back-end servers that have failed? (We're running various versions of Linux on our servers, if that makes any difference.) So...suggestions? How are other people handling load balancing? -John
Re: Load balancers
On 1/13/03 11:12 AM, Ask Bjoern Hansen wrote: On Mon, 13 Jan 2003, John Siracusa wrote: So...suggestions? How are other people handling load balancing? With hardware load balancers. :-) Sure, rub it in ;) You forgot to include the information about number of servers, requests per second at peak times, reponse sizes, etc etc. * four servers * peak of 30 hits/sec (fluctuates though) * response sizes vary: most are less than 20K, but a significant minority are 500K-5MB (i.e. file downloads) But really, stability is out #1 concern right now. Slowdown under load is much more desirable that error under load or lock-up under load :) -John
Re: Load balancers
That's for all the info so far. To answer some questions, hardware is a cost issue right now. It's somewhat scary that $3,200 was a reasonable price several years ago, but I suppose it could be worse. We will investigate further. The mod_rewrite solutions lack dead server detection, and that's something I'd rather not try to roll on my own, especially after seeing how well (or not, actually) existing software solutions do. But I've added it to the list. We're investigating LVS right now. It's kind of disappointing to hear that the mod_perl solution it probably not feasible. Perl solutions are always more fun to implement ;) We chose pound over pen, but we may revisit pen again. I suspect we will have similar problems with our expected load, however. Whackamole, fun name aside, does not seem to be what we need. We don't need the caching part of Squid, and I wasn't aware it did load balancing too. I'll check it out. Thanks for all the info, and please feel free to send me more, especially if there's some gem of a software load balancer out there somewhere... :) -John
Re: Load balancers
On 1/13/03 1:04 PM, Perrin Harkins wrote: John Siracusa wrote: The mod_rewrite solutions lack dead server detection, and that's something I'd rather not try to roll on my own, especially after seeing how well (or not, actually) existing software solutions do. But I've added it to the list. ... It's kind of disappointing to hear that the mod_perl solution it probably not feasible. Perl solutions are always more fun to implement ;) The mod_rewrite option is a Perl solution. You would write some Perl code to manage the availability checks and optionally to provide a new load-balancing algorithm. It's very similar to using mod_perl for it, except you get to skip writing lots of annoying proxy code. But in a full-fledged mod_perl solution, I could back out gracefully and retry another server if I happened to initially choose a dead server before my dead server detection code caught it. With the rewrite solution, I can't think of a reasonable way to keep users from ever getting passed to dead server. (Obviously I can't check the server I plan to send to on every request :) -John
Re: Load balancers
On 1/13/03 1:28 PM, Perrin Harkins wrote: John Siracusa wrote: But in a full-fledged mod_perl solution, I could back out gracefully and retry another server if I happened to initially choose a dead server before my dead server detection code caught it. That sounds cool, but how important is it really? I'm not sure any of these solutions (including the commercial ones) do that level of seamless failover effectively. The five-figure ones better! ;) (they should also make me lunch) -John
Re: Apache::DB and perl 5.80
On 11/28/02 4:13 AM, Michael Maibaum wrote: On Thursday, Nov 28, 2002, at 00:25 US/Pacific, Rob Mueller wrote: I've noticed a few comments around the web of problems with 5.8.0 and Apache::DB, but no responses that anyone is looking at it or has a solution. I've had much the same problem in OS X with 5.8.0, and even asked herebut no-one seemed to know anything (or at least no-one who did noticed my email ;) ) I asked about it as well, and I seem to recall someone responding, saying that it doesn't work now, but top men are working on the problem. (Who? Top...men...) -John
How can I tell if a request was proxy-passed form an SSL server?
Assume I have a front-end (non-mod_perl) proxy server that supports both HTTP and HTTPS. I want to know, from within my Perl code on the back-end (HTTP-only) mod_perl server, if the current request was ProxyPass-ed to me based on an original HTTP or HTTPS request from the user. There doesn't appear to be a way to add headers to the proxy request on a per-virtual-host basis using mod_proxy, and I don't see any other headers that I can use to distinguish between an HTTP or HTTPS front-end server. Any ideas? -John
Re: How can I tell if a request was proxy-passed form an SSLserver?
On 11/14/02 2:12 PM, Randy Kobes wrote: On Thu, 14 Nov 2002, John Siracusa wrote: Assume I have a front-end (non-mod_perl) proxy server that supports both HTTP and HTTPS. I want to know, from within my Perl code on the back-end (HTTP-only) mod_perl server, if the current request was ProxyPass-ed to me based on an original HTTP or HTTPS request from the user. There doesn't appear to be a way to add headers to the proxy request on a per-virtual-host basis using mod_proxy, and I don't see any other headers that I can use to distinguish between an HTTP or HTTPS front-end server. Any ideas? If your front-end proxy server has 'ProxyVia on' enabled, a Via header would get sent. According to rfc2068, the protocol name should, and port may, be supplied in this header if these aren't the defaults - would this be enough to enable your mod_perl server to distinguish between an HTTP or HTTPS request? I tried turning on ProxyVia, but all I got was the HTTP protocol version (1.1) and the host (www.foo.com), but no scheme string (e.g. http://; or https://;) -John
Re: How can I tell if a request was proxy-passed form an SSLserver?
On 11/14/02 2:39 PM, Randy Kobes wrote:
On Thu, 14 Nov 2002, John Siracusa wrote:
I tried turning on ProxyVia, but all I got was the HTTP
protocol version (1.1) and the host (www.foo.com), but no
scheme string (e.g. http://; or https://;)
Were these from requests you know were made using https?
Yep, but I still just get the version number.
My reading of the Via header was that the protocol name is optional
only if it is HTTP, implying that if it's not given, you can
assume it's HTTP.
That doesn't appear to be the case with mod_proxy in apache 1.3.27.
I ended up having to make a trivial C apache module (using the old
mod_proxy_add_forward.c as a basis) to set my own header. Of course, first
I had to find out if the request is SSL. I figured I'd look for the env var
that mod_ssl sets:
https = getenv(HTTPS);
if(https)
ap_table_set(r-headers_in, X-Forwarded-For-SSL, yes);
But that didn't work. (I also tried many of the SSL_* env vars.) So then I
tried looking where mod_ssl actually puts its HTTPS env var, in the
subprocess_env structure:
table *e = r-subprocess_env;
if(ap_table_get(e, HTTPS))
ap_table_set(r-headers_in, X-Forwarded-For-SSL, yes);
But that didn't work either. I forced my trivial module to the end of the
module chain just to make sure mod_ssl got a chance to set its var(s) first,
but that didn't help.
Finally, I found something that did work:
method = ap_ctx_get(r-ctx, ap::http::method);
if(method)
ap_table_set(r-headers_in, X-Forwarded-For-Method, method);
Apparently, this is only set by mod_ssl if method is https. If it is
HTTP, this is not set at all. Anyway, I just check for this on the mod_perl
side with:
if($r-header_in('X-Forwarded-For-Method') eq 'https') { ... }
and that does the trick. The full code for the module is at the end of this
message. But I still think this is an ugly hack, and I'd like to be able to
do this using standard apache modules or config parameters...
-John
---
#include httpd.h
#include http_config.h
#include http_core.h
module MODULE_VAR_EXPORT proxy_add_ssl_module;
static int add_ssl_header(request_rec *r)
{
const char *method;
if(r-proxyreq == PROXY_PASS)
{
method = ap_ctx_get(r-ctx, ap::http::method);
if(method)
ap_table_set(r-headers_in, X-Forwarded-For-Method, method);
return OK;
}
return DECLINED;
}
module MODULE_VAR_EXPORT proxy_add_ssl_module = {
STANDARD_MODULE_STUFF,
NULL, /* initializer */
NULL, /* dir config creater */
NULL, /* dir merger --- default is to override */
NULL, /* server config */
NULL, /* merge server configs */
NULL, /* command table */
NULL, /* handlers */
NULL, /* filename translation */
NULL, /* check_user_id */
NULL, /* check auth */
NULL, /* check access */
NULL, /* type_checker */
add_ssl_header, /* fixups */
NULL, /* logger */
NULL, /* header parser */
NULL, /* child_init */
NULL, /* child_exit */
NULL/* post read-request */
};
Re: How can I tell if a request was proxy-passed form an SSLserver?
On 11/14/02 5:48 PM, Marcin Kasperski wrote: What about the simple manual solution: frontend server proxies /some/url to /http/some/url on backend for HTTP and to /https/some/url on backend for HTTPS. Or something similar... On 11/14/02 6:56 PM, Carolyn Hicks wrote: If you can proxy-pass HTTP and HTTPS requests to different ports on the backend server, you just need to check which port the backend is listening on to tell if the request came through SSL or not. Both of those would work, but aren't quite what I'm looking for. IMO, there should be some way to do what I ended up doing with my little C apache module, namely to add X-Whatever header(s) to a proxy-passed request. I'd imagine something like: Proxy(Add|Set|Unset)Header header value Maybe apache 2.0 has something like that, but I'm still using 1.3.x for now... -John
Apache::Peek and perl 5.8.0
Does anyone have Apache::Peek working with perl 5.8.0? I can't get it to build, and I can't find the symbols it's (apparently) missing anywhere in perl 5.8.0's header files. Example: --- CPAN.pm: Going to build D/DO/DOUGM/Apache-Peek-0.9501.tar.gz Checking if your kit is complete... Looks good Writing Makefile for Apache::Peek cp Peek.pm blib/lib/Apache/Peek.pm /usr/local/bin/perl /Library/Perl/ExtUtils/xsubpp -typemap /Library/Perl/ExtUtils/typemap Peek.xs Peek.xsc mv Peek.xsc Peek.c Please specify prototyping behavior for Peek.xs (see perlxs manual) cc -c -I/Library/Perl/darwin/auto/Apache/include -I/Library/Perl/darwin/auto/Apache/include/modules/perl -I/Library/Perl/darwin/auto/Apache/include/include -I/Library/Perl/darwin/auto/Apache/include/regex -I/Library/Perl/darwin/auto/Apache/include/os/unix -I/usr/include/httpd -pipe -fno-common -no-cpp-precomp -fno-strict-aliasing -O3 -DVERSION=\0.9501\ -DXS_VERSION=\0.9501\ -I/Library/Perl/darwin/CORE -DMOD_PERL Peek.c Peek.xs: In function `DumpOP': Peek.xs:316: `GVOP' undeclared (first use in this function) Peek.xs:316: (Each undeclared identifier is reported only once Peek.xs:316: for each function it appears in.) Peek.xs:316: parse error before ')' token Peek.xs:318: parse error before ')' token ... --- ...and so on. Anyway, I can't even find GVOP in /Library/Perl/darwin/CORE/*.h, which makes me wonder if it's just plain incompatible with 5.8.0 (the docs don't seem to mention anything about it) -John
Re: Trouble with Apache::DB
On 10/24/02 11:18 PM, Kip Cranford wrote: I have a newly installed Red Hat 8.0 system, with the following characteristics: * Perl v5.8.0 * mod_perl 1.27 * Apache 1.3.26 The build of mod_perl/Apache worked fine; the project I had been working on before upgrading RH seems to run ok. However, today I attempted to debug something using Apache::DB and running with httpd -X. I received this error: [error] No DB::DB routine defined at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache.pm line 4. I got a similar error a while back when I tried it with the same versions of Perl, mod_perl, and apache (but on Mac OS X). I googled a while and all I could come up with were some posts from internals hackers about perl data structures getting mysteriously hosed for some unknown reason with this collection of versions. I still haven't found a solution... -John
Re: Change in module naming conventions
On Tuesday, August 27, 2002, at 10:54 PM, Stas Bekman wrote: But Authentication, Authorization and Access aren't all Auth. May be using Apache::AAA:: as in httpd-2.0/modules/aaa/ ? Please, no more too-clever TLAs. Have we learned nothing from LWP? :) -John
Re: IPC::Open2 under mod_perl in Mac OS X
On 6/30/02 2:06 AM, Stas Bekman wrote: John Siracusa wrote: (I'm not sure if this is a mod_perl thing of a Mac OS X bug, so I'm posting it to both lists. Redirect follow-ups as appropriate.) open2() doesn't seem to work for me when running under mod_perl in Mac OS X. It's not a bug in MacOSX, it simply doesn't work with mod_perl. I can't post a direct example now (because I don't have access to the machine from here), but I'm pretty sure I do have an example of open2() working under mod_perl in Linux--in a perl that is not compiled with sfio. That's why I thought it was a Mac OS X bug. The mod_perl guide talks about the output from system(), exec(), and open(F, | ...) not being sent to the browser, but it doesn't mention open2(). In the case of open2(), the input and output is supposed to be tied to filehandles that I supply, not connected to mod_perl's (tied?) STDOUT that eventually goes to the browser. So could you clarify why open2() is not expected to work under mod_perl, and why it seems to work for me in Linux? (I'll post the working Linux example once I can confirm it on Monday.) -John
IPC::Open2 under mod_perl in Mac OS X
(I'm not sure if this is a mod_perl thing of a Mac OS X bug, so I'm posting it to both lists. Redirect follow-ups as appropriate.) open2() doesn't seem to work for me when running under mod_perl in Mac OS X. Here's the test case: In /usr/local/bin/upcase #!/usr/bin/perl $buf .= $_ while(STDIN); print uc $buf; Example usage from the command line: % echo hello | upcase HELLO Now here's the CGI script that uses open2() to talk to the upcase program: #!/usr/bin/perl use strict; use CGI qw(:standard); use IPC::Open2; open2(\*READ, \*WRITE, '/usr/local/bin/upcase'); print WRITE Hello; close(WRITE); my $res; $res .= $_ while(READ); close(READ); print header(), Got: $res Running it under plain CGI shows the expected output: Got: HELLO But running it under Apache::PerlRun or Apache::Registry shows: Got: Any ideas? (Some more verbose configuration information is included below.) -John % perl -V 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 . % uname -a Darwin xxx.com 5.5 Darwin Kernel Version 5.5: Thu May 30 14:51:26 PDT 2002; root:xnu/xnu-201.42.3.obj~1/RELEASE_PPC Power Macintosh powerpc Apache/1.3.23 (Darwin) mod_perl/1.26 (I've also tried this with apache 1.3.26 and got the same results) % httpd -V Server version: Apache/1.3.23 (Darwin) Server built: 02/16/02 15:51:05 Server's Module Magic Number: 19990320:11 Server compiled with -D HAVE_MMAP -D USE_MMAP_SCOREBOARD -D USE_MMAP_FILES -D HAVE_FCNTL_SERIALIZED_ACCEPT -D HAVE_FLOCK_SERIALIZED_ACCEPT -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D HTTPD_ROOT=/usr/local/apache -D SUEXEC_BIN=/usr/local/apache/bin/suexec -D DEFAULT_PIDLOG=logs/httpd.pid -D DEFAULT_SCOREBOARD=logs/httpd.scoreboard -D DEFAULT_LOCKFILE=logs/httpd.lock -D DEFAULT_XFERLOG=logs/access_log -D DEFAULT_ERRORLOG=logs/error_log -D TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf -D ACCESS_CONFIG_FILE=conf/access.conf -D RESOURCE_CONFIG_FILE=conf/srm.conf % httpd -l Compiled-in modules: http_core.c mod_env.c mod_log_config.c mod_mime.c mod_negotiation.c mod_status.c mod_include.c mod_autoindex.c mod_dir.c mod_cgi.c mod_asis.c mod_imap.c mod_actions.c mod_userdir.c mod_alias.c mod_access.c mod_auth.c mod_setenvif.c mod_perl.c suexec: disabled; invalid wrapper /usr/local/apache/bin/suexec
Re: mod_perl/passing session information (MVC related, maybe...)
On 6/13/02 11:04 AM, Rob Nagler wrote: With sessionID, you have an ID and information that is checksum'd. Sessions and user IDs are equivalent. They are called credentials which allow access to a system. There's no fundamental difference between hijacking a session or stealing a user id/password. Well, given a user/pass, you can login form anywhere. Given a session that's tied to information like the remote IP, user agent, date, etc. etc., it's a lot harder to reuse that information to login from elsewhere. -John
Re: separating C from V in MVC
On 6/13/02 1:29 PM, Perrin Harkins wrote:
Just be careful that you don't end up making this into something that
mirrors the SQL exactly. There might be 4 tables involved in finding
out what kind of credit card the user had, but that gets hidden behind
this API. If you find yourself writing classes that take options like
where = 'date ' . $date you are reinventing SQL, and you've lost
your abstraction.
Stringy stuff like that is certainly a poor abstraction (or no abstraction
at all if it's stuck directly into the SQL!) But I've done stuff like this:
Pets-get_pets(type = [ 'dog', 'cat' ],
age = { and = { gt = 5, lt = 10 } },
name = { match = 'Fi.*' });
which is powerful enough to do most types of basic selects, but still
abstract enough that the user of this class never actually types SQL
fragments directly.
Of course, the case above is a rarity. Usually, it'll be used in the simple
form like:
Pets-get_pets(type = 'dog', age = 5);
But just having that more complex form in there for the one or two times you
need it is sometimes valuable, IMO. And the overhead is minimal if you have
a nice base class that supports all this stuff for you.
-John
Re: threads in 5.8 (was: mod_perl2.0 / TIPool)
On 6/13/02 5:58 PM, Matt Sergeant wrote: Also note perl.com is now running an article on threads::shared. http://www.perl.com/pub/a/2002/06/11/threads.html It's mainly aimed at module authors, but it could be of interest anyway. Does anyone know the logic behind making the threads modules all lowercase? I'd expect it to be Threads::Shared, not threads::shared. -John
Re: threads in 5.8 (was: mod_perl2.0 / TIPool)
On 6/13/02 6:40 PM, Matt Sergeant wrote: Does anyone know the logic behind making the threads modules all lowercase? I'd expect it to be Threads::Shared, not threads::shared. Pragmas are lowercase. And use threads; is really a pragma. A pragma with class methods? A pragma that exports functions? Maybe I'm confused about the distinction between a pragma and a module... -John
Re: mod_perl/passing session information (MVC related, maybe...)
On 6/12/02 12:57 PM, Per Einar Ellefsen wrote: But what if someone opens one of the links in a different window, and continue on the same pages as in the original window, but with different parameters? The session ID would be the same, the context id would be the same, but the params would be different, right? Well, then things break I guess... :) Maybe you could do some magic based on what browsers send as the referrer when users explicitly open a link in a new tab or window? Probably not worth it... -John
Re: separating C from V in MVC
On 6/11/02 12:46 PM, Perrin Harkins wrote: John Hurst wrote: Still, I don't think that replacing this: Location /search SetHandler perl-script PerlHandler Controller::Search /Location with this: [% Ctrl.Search() %] makes Controller::Search any less a controller. You're right. It just looks kind of odd to me, invoking a template for something that is not a display-related task. It looks like the way people typically do MVC in Mason or Embperl, with a first template that doesn't do anything but invoke a module to take over the processing. ...but it has several advantages. I particularly appreciate being able to add to or change parameters or behaviors before passing things off to the controller, for example. I can have several variants of the same controller living at different URLs, all pointing back to a single controller object. Don't think of it as invoking a template. Just think off it as an inverted dispatch mechanism: the actions camp out at their locations, as opposed to having their locations (in the httpd.conf) pointing at the controller modules. Or something... :) -John
Re: [OT] MVC soup (was: separating C from V in MVC)
On 6/7/02 1:04 PM, Perrin Harkins wrote:
For example, if you have a form for registering as a user which has
multiple fields, you want to be able to tell them everything that was
wrong with their input (zip code invalid, phone number invalid, etc.),
not just the first thing you encountered.
Putting that into a model object is awkward, since coding your
constructor or setter methods to keep going after they've found the
first error feels wrong. You can write a special validate_input()
method for it which takes all the input and checks it at once returning
a list of errors. You could also just punt and push this out to the
controller. (Not very pure but simple to implement.) Either way you
can use one of the convenient form validation packages on CPAN.
I use my form objects to do this. For example, to process a create user
form, the controller creates the form object:
$form = My::Form::User::Edit-new;
Initializes it based on the form submission:
$form-init($form_params);
runs the form object's validate() method:
unless($form-validate)
{
...
and then (if the validation fails) passes the initialized form objects to
back to the view:
$app-edit_user_page(form = $form);
There are per-field and per-form errors which are set during the validate()
step. The view decides where, how, and if to display these.
Going in the reverse direction (say, editing an existing user), the
controller creates the form again:
$form = My::Form::User::Edit-new;
gets the user object (and handles errors, yadda yadda):
$user = My::Users-get_user(id = $id) || ...;
initializes the form with the model object:
$form-init_with_user($user);
and then passes the form to the view:
$app-edit_user_page(form = $form);
The details have been heavily simplified above, but that's the general idea.
I'm not sure how this all fits into MVC, but it works very well for my
purposes.
-John
Re: separating C from V in MVC
On 6/4/02 12:32 PM, Perrin Harkins wrote:
The thing that worries me about a widget approach is that I would have
the same problem I had with CGI.pm's HTML widgets way back: the
designers can't change the HTML easilly. Getting perl developers out of
the HTML business is my main reason for using templating.
My approach uses an intentionally limited subset of Mason as my templating
language. It looks something like this:
* Model: Regular Perl classes and objects.
* Controller: Regular Perl classes and objects, trivially wrapped in Mason
components to control access location (i.e. URL), object caching, and so on.
* View: Mason components that receive widget-like objects as well as
simple strings and other params.
To try to solve the designers don't know Perl problem, I just constrain
the API usage of the widget objects for designers. Example:
tr
td% $form-field('name')-html_label %/td
td% $form-field('name')-html_field %/td
/tr
As concerned as I initially was by this syntax, the fact is that 99% of all
view objects have a series of exactly the same calls. Designers have no
clue what they do internally, but the fact is that the only part that really
changes is the field name. And there are very few, simple method names to
know: html_field, html_label, html_error, etc. In the simplest case,
there's even a few places where this works:
% $form-field('name')-html %
And handles the label (if any), field, and field-tied error message all in
one block. I guess the moral is that comfort != understanding. Designers
can get comfortable with even ugly syntax like the above very quickly
since it is repeated so often.
Yes, this means that all the nuts and bolts of what gets printed by those
calls is handled by the controller object (which produces the widgets,
populating them according to the data form the model objects), and therefore
the programmer. But IMO this is as it should be. The programmer flags
which form fields are required, what HTML surrounds error messages
(usually just span class=error) and so on. The designers change the
contents of the style sheets, make the graphics, and arrange the widgets on
the page.
And in a pinch, the programmer does have the full range of Mason features
available. IMO, it's not much harder for designers to learn some small
subset of a larger syntax (like Mason/Perl-Widget-API) than it is for them
to learn an equal size subset (or entirety) of a little language like
template toolkit.
-John
HTML::Entities chokes on XML::Parser strings
I ran into this problem during mod_perl development, and I'm posting it to
this list hoping that other mod_perl developers have dealt with the same
thing and have good solutions :)
I've found that strings collected while processing XML using XML::Parser do
not play nice with the HTML::Entities module. Here's the sample program
illustrating the problem:
#!/usr/bin/perl -w
use strict;
use HTML::Entities;
use XML::Parser;
my $buffer;
my $p = XML::Parser-new(Handlers = { Char = \xml_char });
my $xml = '?xml version=1.0 encoding=iso-8859-1?test' .
chr(0xE9) . '/test';
$p-parse($xml);
print encode_entities($buffer), \n;
sub xml_char
{
my($expat, $string) = _;
$buffer .= $string;
}
The output unfortunately looks like this:
Atilde;copy;
Which makes very little sense, since the correct entity for 0xE9 is:
eacute;
My current work-around is to run the buffer through a (lossy!?) pack/unpack
cycle:
my $buffer2 = pack(C*, unpack(U*, $buffer));
print encode_entities($buffer2), \n;
This works and prints:
eacute;
I hope it is not lossy when using iso-8859-1 encoding, but I'm guessing it
will maul UTF-8 or UTF-16. This seems like quite an evil hack.
So, what is the Right Thing to do here? Which module, if any, is at fault?
Is there some combination of Perl Unicode-related use statements that will
help me here? Has anyone else run into this problem?
-John
Re: HTML::Entities chokes on XML::Parser strings
On 5/7/02 10:58 AM, Paul Lindner wrote: The output from your example looks like UTF-8 data (Atilde; is a commonly seen UTF-8 escape sequence). XML::Parser converts all incoming text into UTF-8. You will need to convert it back to iso-8859-1. My favorite is Text::Iconv use Text::Iconv; $utf8tolatin1 = Text::Iconv-new(UTF-8, ISO8859-1); my $buffer_latin1 = $converter-convert($buffer); So HTML::Entities only works with ISO8859-1 (or ASCII, presumably)? What if I have actual UTF-8 data? Won't conversion to ISO8859-1 in service of HTML::Entities result in data loss? -John
Re: HTML::Entities chokes on XML::Parser strings
On 5/7/02 11:06 AM, Rafael Garcia-Suarez wrote:
The workaround I used is to write the handler like this :
sub xml_char
{
my ($expat) = _;
$buffer .= $expat-original_string;
}
Reading the original string, no need to convert UTF-8 back to iso-8859-1.
Doh! I dunno why I didn't think of that, since I've used that expat method
plenty of times before. This seems safer than forcing a conversion from
UTF-8 to something else (although the other technique is nice to know too :)
-John
Re: HTML::Entities chokes on XML::Parser strings
On 5/7/02 11:25 AM, Gisle Aas wrote: John Siracusa [EMAIL PROTECTED] writes: On 5/7/02 10:58 AM, Paul Lindner wrote: The output from your example looks like UTF-8 data (Atilde; is a commonly seen UTF-8 escape sequence). XML::Parser converts all incoming text into UTF-8. You will need to convert it back to iso-8859-1. My favorite is Text::Iconv use Text::Iconv; $utf8tolatin1 = Text::Iconv-new(UTF-8, ISO8859-1); my $buffer_latin1 = $converter-convert($buffer); So HTML::Entities only works with ISO8859-1 (or ASCII, presumably)? Not true. But the unicode support in perl-5.6.x has many bugs. With 5.8 things will be better. It is a bad idea for XML::Parser to give out strings with the UTF8 flag set. Well, I'll let your guys figure it out (all fixed in 5.8, right? :) In the meantime, I guess I'll stick with the workaround(s) posted... :) -John
Re: [announce] mod_perl-1.99_01
On 4/8/02 2:41 AM, Stas Bekman wrote: I've searched google, but didn't find any info regarding Term::ANSIColor and suggesting good cross-platform, cross-terminal colors. Maybe I didn't understand the earlier part of your message, but can't you specify both the foreground and the background color of text? It'd be ugly, but if you specified both you could be (relatively) sure the colors would show up. If you really want to be safe, you can use an old-style attention-grabbing technique like this: ** ## ** WARNING!!! ** ## ** blah blah blah ** ## ** WARNING!!! ** ## ** People will see stuff like that :) Or you could take the high road and just print it normally. As long as it's the last thing printed (i.e. It doesn't scroll by while they're away or in another window), people will probably read it :) And if not, it could be argued that they get what they deserve ;) -John
Re: [announce] mod_perl-1.99_01
You might want to reconsider the use of VT escape codes in the build process. The red error message was cute, but there's a big potential downside (see attached screenshot). In the words of the W3C's CSS validator: You have no background-color with your color :) -John not-so-clever.gif Description: GIF image
Re: Be carefull with apache 1.3.24
On 3/23/02 8:01 PM, Pedro Melo Cunha wrote: Looking at the change log, they mention a bug that multiple set-cookie's will fail (only the last one will be sent to the client, the proxy will eat the others). And it was true... The problem is that 1.3.24 final also has that bug: only the last set-cookie will reach your browser. This was a show-stopper for my application. So I sat down, read the proxy code, and made a patch to solve the bug. Applied the attached patch to 1.3.24, but it complained: --- % patch -i ../mod_proxy_patch.diff src/modules/proxy/proxy_http.c patching file src/modules/proxy/proxy_http.c Reversed (or previously applied) patch detected! Assume -R? [n] y --- I'm not sure what that means, but I forced it through anyway, and the bug remains! (As tested by your attached cookie.cgi script.) Just to make sure I wasn't crazy, I also re-tried my unpatched version of 1.3.24 and it showed the bug too. So, what's the status on this? Is 1.3.25 due out soon to fix this? Does anyone have a working patch? -John
Re: Be carefull with apache 1.3.24
On 3/29/02 1:11 PM, John Siracusa wrote: On 3/23/02 8:01 PM, Pedro Melo Cunha wrote: Looking at the change log, they mention a bug that multiple set-cookie's will fail (only the last one will be sent to the client, the proxy will eat the others). And it was true... The problem is that 1.3.24 final also has that bug: only the last set-cookie will reach your browser. This was a show-stopper for my application. So I sat down, read the proxy code, and made a patch to solve the bug. Applied the attached patch to 1.3.24, but it complained: --- % patch -i ../mod_proxy_patch.diff src/modules/proxy/proxy_http.c patching file src/modules/proxy/proxy_http.c Reversed (or previously applied) patch detected! Assume -R? [n] y --- I'm not sure what that means Heh, n e v e r m i n d... :) Anyway, now that I have patched, working versions, what's the status on apache.org fixing this bug in the real distribution? -John
Re: Be carefull with apache 1.3.24
On 3/29/02 1:26 PM, John Siracusa wrote: Anyway, now that I have patched, working versions... Scratch that: the patch doesn't seem to work when I build a server with mod_ssl in it. Hrm... -John
Re: Be carefull with apache 1.3.24
Does anyone know how I can put my ProxyIOBufferSize config line in a conditional that'll keep it from blowing up if I'm using a version of apache earlier than 1.3.24? -John
Re: Be carefull with apache 1.3.24
On 3/25/02 11:39 AM, Geoffrey Young wrote:
In /path/to/apache1.3.24/bin/apachectl add a -DAPACHE_1_3_24 to the
httpd command.
In your httpd.conf add
IfDefined APACHE_1_3_24
ProxyIOBufferSize 10
/IfDefined
I think that should work
you could also do something hackish like this to avoid command line switches
Perl
my ($version) = Apache::Constants::SERVER_VERSION =~ m/(\d{2})/;
$ProxyIOBufferSize = 1 if $version = 24
/Perl
I don't want to use defines if I can help it, and it's a proxy server
without mod_perl, so the Perl section is out. Hm, you'd think apache
would have a directive for this, especially since it pukes when it sees
unknown conf directives. Maybe I'll go nag the apache devs... :)
-John
Multiple Location directives question
I have something like: Location /foo SetHandler perl-script PerlHandler My::Foo /Location Location / SetHandler perl-script PerlHandler My::Bar AuthName Bar AuthType Basic PerlAuthenHandler My::Auth::Bar PerlAuthzHandler My::Authz::Bar require valid-user /Location What I want is for My::Foo to handle all URLs that start with /foo, without any authentication of any kind Then I want the remaining URLs to be handled by My::Bar using its authentication handlers What I get is that My::Bar handles everything Changing the order of the Location directives doesn't seem to help The Apache docs say that Location directives are done simultaneously, whatever that means So, any pointers? -John
Re: Multiple Location directives question
On 3/5/02 11:58 AM, Geoffrey Young wrote: you might want to set up /foo and /bar then use mod_rewrite or something to map !/foo to /bar Ug, there has to be another way :-/ -John
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
Re: MacOSX Requests and Cookies
On 2/1/02 10:39 PM, Joe Schaefer wrote: Rick Frankel [EMAIL PROTECTED] writes: The following patch, while probably not correct (and probably the cause of the silent failure), covers it. [...] I've incorporated your patch and uploaded it to the website. Hopefully other OS X'ers will be able to confirm it works now. 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. I tried to track exactly what I was doing, command-line by command-line, starting with the downloads from Joe's site, but that kind of got tossed away when I had to make that excursion to fix the perl500503 business. I'll try again today and see if I can work out clean line-by-line example that exhibits the continued failure on my end. -John
Re: Apache::args vs Apache::Request speed
On 2/1/02 3:39 PM, Ian Ragsdale wrote: On the other hand, I'd be happy to compile it, but what would I need to do to test it? I'm in the process of trying this too (just building a mod_perl httpd in OS X is a bit tricky...) To test it, I think all you need to do is put these two lines in your startup.pl file (or whatever): use Apache::Request; use Apache::Cookie; If that works, the next step is to make an actual apache handler that uses both the modules to actually do something. And if that works, post detailed instructions (starting with the wget of the source tarballs :) -John
Re: Apache::args vs Apache::Request speed
On 2/1/02 3:21 PM, Joe Schaefer wrote: Would someone PLEASE volunteer to try to compile and test apache+mod_perl libapreq on OS/X using the experimental code I posted there? Even if you can't get it working, ANY feedback about what happened when you tried would be VERY helpful. (The below may not be very helpful, but I've gotta run right now. I'll try more this weekend if I can.) An initial build and install of: http://www.apache.org/~joes/libapreq-1.0-rc1.tar.gz on a previously-working apache 1.3.22 mod_perl 1.26 server on OS X 10.1.2 with this: use Apache::Request; use Apache::Cookie; In its startup.pl file causes the following: # bin/httpd -d /usr/local/apache -f conf/httpd.conf dyld: bin/httpd Undefined symbols: _ap_day_snames _ap_find_path_info _ap_get_client_block _ap_getword _ap_getword_conf _ap_hard_timeout _ap_ind _ap_kill_timeout _ap_log_rerror _ap_make_array _ap_make_dirstr_parent _ap_make_table _ap_month_snames _ap_null_cleanup _ap_pcalloc _ap_pfclose _ap_pfdopen _ap_popenf _ap_psprintf _ap_pstrcat _ap_pstrdup _ap_pstrndup _ap_push_array _ap_register_cleanup _ap_setup_client_block _ap_should_client_block _ap_table_add _ap_table_do _ap_table_get _ap_table_set _ap_table_unset _ap_unescape_url _hvrv2table _mod_perl_tie_table _perl_request_rec _sv2request_rec More later, I hope... :) -John
Re: Apache::args vs Apache::Request speed
On 1/27/02 3:34 PM, Joe Schaefer wrote: param() was rewritten as XS about 6-8 months ago; since then I've benchmarked it a few times and found param() to be a bit faster than args(). We'll be releasing a 1.0 version of libapreq as soon as Jim approves of the current CVS version. Did I just read that there's a new version of libapreq coming? If so, will it: a) eliminate the current confusion between J/JI/JIMW/libapreq-0.33.tar.gz and D/DO/DOUGM/libapreq-0.31.tar.gz by creating a unified libapreq distribution with a version number greater than both of the above, and b) actually work in Mac OS X (please please please!) (See: http:[EMAIL PROTECTED]/msg01124.html) -John
Re: mod_accel-1.0.10 and mod_deflate-1.0.10
On 12/29/01 8:23 AM, Igor Sysoev wrote: ftp://ftp.lexa.ru/pub/apache-rus/contrib/mod_accel-1.0.10.tar.gz Is there any timeline on a release of mod_accel with English documentation? -John
Re: OT: secure mod_perl enabled apache on MacOSX 10.1
On 10/4/01 9:26 AM, Joe Schaefer wrote: John Siracusa [EMAIL PROTECTED] writes: P.S.- d) Apache::Request and Apache::Cookie still can't be loaded simultaneously! :( Why not? Run-time symbol conflict. Does it work OK with a statically-linked mod_perl? I've never heard of anyone getting it to work correctly in any version of Mac OS X with any sort of apache or Perl installation. (if you're out there, tell us how! :) -John
Re: OT: secure mod_perl enabled apache on MacOSX 10.1
On Wednesday, October 3, 2001, at 05:03 PM, Ray Zimmerman wrote: At 2:23 PM -0400 10/3/01, John Siracusa wrote: On Wednesday, October 3, 2001, at 02:10 PM, Ray Zimmerman wrote: I've been able to build a mod_perl enabled apache (not DSO) for Mac OS X 10.1 and it seems to work fine. Would it be too much trouble for you to post a complete, step-by-step account of exactly what you did you accomplish this? :) OK, this is with apache_1.3.20, perl-5.6.1 and mod_perl-1.26. How did you build and install Perl 5.6.1? -John
Re: OT: secure mod_perl enabled apache on MacOSX 10.1
On Wednesday, October 3, 2001, at 02:10 PM, Ray Zimmerman wrote: I've been able to build a mod_perl enabled apache (not DSO) for Mac OS X 10.1 and it seems to work fine. Would it be too much trouble for you to post a complete, step-by-step account of exactly what you did you accomplish this? :) -John
Re: mod_perl IPC under Solaris 7
Here's my long-winded setup. I'm not sure how smart or dumb these settings are, but they work for me on a machine with 1GB or RAM. Note that I had to change the semaphore settings too to get IPC::SharedCache to work without complaint. -John --- * * Shared memory settings changed by John Siracusa 9/19/2000 * * Maximum size of system V shared memory segment that can be * created. This parameter is an upper limit that is checked before the * system sees if it actually has the physical resources to create the * requested memory segment (default 1048576, max MAXINT/MAXINT64) set shmsys:shminfo_shmmax = 8388608 * Minimum size of system V shared memory segment that can be created * (default 1, max amount of physical memory * set shmsys:shminfo_shmmin = 1 * System wide limit on number of shared memory segments that can be * created (default 100, max MAXINT) set shmsys:shminfo_shmmni = 1 * Limit on the number of shared memory segments that any one process * can create (default 6, max 32767) set shmsys:shminfo_shmseg = 1 * * Semaphore settings changed by John Siracusa 9/19/2000 * * Maximum number of semaphore identifiers (default 10, max 65535) set semsys:seminfo_semmni = 6 * Maximum number of System V semaphores on the system (default 60, max MAXINT) set semsys:seminfo_semmns = 50 * Maximum value a semaphore can be set to (default 32767, max 65535) * set semsys:seminfo_semvmx = 6 * Max number of semaphores per semaphore identifier (default 25, max MAXINT) * set semsys:seminfo_semmsl = 100 * Maximum number of System V semaphore operations per semop(2) * call. This parameter refers to the number of sembufs in the sops * array that is provided to the semop() system call (default 10, max MAXINT) * set semsys:seminfo_semopm = 50 * Maximum number of System V semaphore undo structures that can be * used by any one process (default 10, max MAXINT) * set semsys:seminfo_semume = 50 * Maximum value that a semaphore's value in an undo structure can be set to * (default 16385, max 65535) * set semsys:seminfo_semaem = 6 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: shared mem [was: mod_perl advocacy project resurrection]
On 12/6/00 3:42 PM, Paul wrote: The parent process could declare a shared memory segment at boot time. Each child's init could spawn a shared memory interface object. Wouldn't that allow for some resource pooling to be cleaner? How would that interact with per-child namespaces (if at all)? IPC::SharedCache and friends make this pretty simple. -John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pre-loaded modules on Solaris
On 11/10/00 10:15 AM, John Hughes wrote: A guess: When pmap says "shared" it means stuff that realy shared. I.E. it's not counting stuff that is marked copy-on-write, which is shared UNTIL YOU TRY TO MODIFY IT. Is there any way to measure the size of the shared copy-on-write pages on Solaris? It seems insane that everyone just "assumes" that all this copy-on-write goodness is happening, despite (seemingly) no way to measure it. I'll admit, it's always been my assumption too, but I'd really like some hard numbers to back me up. -John
Re: [OT] amp; in URLs (was: Re: Templating System)
On 7/28/00 12:54 PM, Mark Doyle wrote: We deliberately chose to use URL's with a series of '/' delimited fields rather then using '? ... ' style URL's precisely because most people don't know they have to escape the ampersands and we didn't want to risk people's links breaking in the future because of some new entity in the HTML spec. Another alternative (and one I use sometimes) is to do: .../blah?foo=1;goo=hoo;etc=andsoon which CGI.pm conveniently understands and parses, and is valid in HREFs, AFAIK. -John
Re: [request] live server updates + ideas for guide/control.html
On 5/2/00 2:19 PM, Stas Bekman wrote: 2. The other request is about the "Controlling and Monitoring the Server" chapter itself. Do you think that in addition to the existing items (see below) you/we want to see other things related to this chapter. I'd like to see an example of how to control one web server from another web server (i.e. via a CGI tool) Sort of a simple web interface to apachectl, but one that can control apache running on a privileged port (e.g. 80) even when the admin web server itself is not running as root. -John
Re: RFD: comp.infosystems.www.modperl
On 2/3/00 1:17 PM, Bill Jones wrote: however, that doesn't mean that the 'experts' will frequent the newsgroup more than a mailing list - people tend to start flame wars more in a usenet setting... OTOH, it's a lot easier to track and respond to particular issues/problems in a threaded setting like Usenet. On the mailing list, only one or two problems seem to be "active" at any one time. Perhaps not now, but eventually it'd be beneficial to have a newsgroup. I know Usenet is the first place I looked for mod_perl help before finding this list (and after finding, buying, and reading the Eagle book ;) -John
Re: Handling directory requests with a PerlHandler
On 11/11/99 7:49 PM, John Siracusa wrote:
$uri .= 'index.html';
# /dir/ is now /dir/index.html
my($sr) = $r-lookup_uri($uri);
return $sr-run();
it appears to work, but the headers I get are simply:
HTTP/1.0 200 OK
Date: Fri, 12 Nov 1999 00:25:44 GMT
No content type! I've tried explicitly setting $sr's content_type()
before I run() it and that doesn't work either.
In the grand tradition of asking for help, I solved this bit seconds
after I sent the email :)
my($sr) = $r-lookup_uri($uri);
$r-send_http_header('text/html');
return $sr-run();
The bit I was missing was that I have to call send_http_header() on the
*original* request object $r, not the subrequest $sr.
I'm still not sure how to correctly search for "index-ish" files
(as per the server configuration) rather than explicitly tacking on
the constant string "index.html", however. How does apache do this
internally?
-John
Using Apache::Util outside mod_perl
Can I use the Apache::Util functions outside mod_perl? Here's an attempt:
% cat test.pl
use Apache::Util;
print Apache::Util::escape_html('foo');
% perl test.pl
Undefined subroutine Apache::Util::escape_html called at test.pl line 3.
I'd like to have access to the fast URL/HTML escaping subroutines
in "regular" perl scripts, if possible.
-John
Re: Using Apache::Util outside mod_perl
On 11/1/99 12:19 PM, Ken Y. Clark wrote: I'd like to have access to the fast URL/HTML escaping subroutines in "regular" perl scripts, if possible. isn't that functionality available in CGI? Yes, but AFAIK they're plain perl implementations rather than stubs for faster C versions. -John
Re: Intentional Premature Finish in an Apache Module
On 10/28/99 1:31 PM, Ken Y. Clark wrote: for what it's worth, here's what i do: [snip] my $err = $r-pnotes(ERROR_NAME) or return OK; Speaking of pnotes(), how stable, API-wise, is it? It isn't documented at all in the O'Reilly Apache Modules book, but I was very happy to find it in the Apache.pm docs. -John
Apache::Cookie confusion
Apache::Cookie seems to have two different interfaces...or maybe there
are two different distributions of Apache::Cookie? Whatever it is, the
interface seems different on two machines here at work. One has 5.004
and one has 5.005, but that shouldn't change the Apache::Cookie interface
should it?
The interfaces are totally different. One uses set() and get(), either
from an object or via Apache::Cookie-get(). The other purports to
use the CGI::Cookie interface but only accepts the methods it documents
itself: fetch(), bake(), etc.
In my code, I "use Apache::Cookie" and then bang away trying to figure
out what methods it supports. The result is that the code on machine1
that calls Apache::Cookie-get('mycookie') dies with an undefined
subroutine error when run on machine2 (and vise versa for code on
machine2 that uses fetch() and bake()).
What am I missing here? I've done "force install Apache::Cookie"
from the CPAN shell prompt several time to try to make sure everything
is in sync, but the discrepancy still exists, and I still don't know
what the correct interface to Apache::Cookie should be. My hunch is
that the get() and fetch() versions are completely separate modules
that both declare "package Apache::Cookie", but good old CPAN should
allow that, should it?
Can someone set me straight?
-John
P.S.-Documentation snippets from the two machines:
On machine 1:
% perldoc Apache::Cookie
NAME
The Apache::Cookie module - An OO interface to cookies based
on CGI::Cookie, for use in mod_perl Apache modules.
SYNOPSIS
use Apache::Cookie;
$r = Apache-request;
# Object oriented
$cookie = Apache::Cookie-new($r);
$cookie-set(-name = 'cookie', -value = 'monster');
$value = $cookie-get('cookie');
...
On machine 2:
% perldoc Apache::Cookie
NAME
Apache::Cookie - HTTP Cookies Class
SYNOPSIS
use Apache::Cookie ();
my $cookie = Apache::Cookie-new($r, ...);
DESCRIPTION
The Apache::Cookie module is a Perl interface to the cookie
routines in libapreq. The interface is based on Lincoln
Stein's CGI::Cookie module.
...
