Re: Real Widgets and Template Languages
Gunther Birznieks [EMAIL PROTECTED] writes:
However, I think it is reasonable to make the interface to support a
data source for the widgets flexible and object based to make it easy
for someone to write a DBI source, a DBM source, an LDAP source, an
Apache::Session source or whatever anyone wants really. I happen to
think DBI and Session sources are cool.
I agree; unfortunately writing classes to interface to all of these
would be difficult, and it would be difficult to be futureproof. When
you hit LDAP and DBI you must then worry about databases, tables,
servers, usernames, passwords, etc. It can become cumbersome to do
the simple things.
By default, it could be GPC chaining like PHP (Get, Post,
Cookie) But with enough widget data sources to choose from you
could do
GPCSD (Get, Post, Cookie, Session, Database) type of thing.
This can be done quite well from a closure:
my $dbh = DBI-connect(...);
my $sth = $dbh-prepare('SELECT foo FROM persistant_data WHERE id = ?');
my $cgi = new CGI;
my $data_closre =
sub {
my $key = shift;
my $return = $cgi-param($key);
$return = $cgi-cookie($key)
unless defined $return;
if (not defined $return) {
$sth-execute($key);
($return) = $sth-fetchrow;
$sth-finish;
}
return $return;
};
Now the closre, though slightly more complicated, doesn't need to know
anything about the world around it, and neatly cinches off the
interface from Widget into DBI, CGI, cookies, etc etc. Using classes
for this would work, but it could be cumbersome; a closure allows for
near infinite flexibility... but at the price of complexity.
I think but am not sure that closures likely also have better
performance than method lookups. If this is the case, it could make
sense to support a few data sources that need high performance because
of their common use: CGI.pm and Apache::Request. Yet provide the
extensibility for other developers to inject their own data sources
into the chain using an Object-based API.
Closures are indeed faster than both instance method calls and package
method calls. However, this is a very basic thing; if performance is
critical enough to optimize this portion of a program then likely
someone wouldn't be using Widgets anyway :)
Maybe someone else could comment on the technical merit of closure vs
objects as well as the way in which they have been expecting the
widgets to get populated? Is what I am saying make sense?
Below is a script to benchark the various invocations. The baseline
is for a function (method, closure, package method) to take one data
parameter and return something based on it.
The results I get on a dual P3 500 are:
[cturner@magneto cturner]$ perl bench.pl
Benchmark: timing 400 iterations of closure, method, pkgmethod...
closure: 10 wallclock secs ( 9.88 usr + 0.00 sys = 9.88 CPU) @ 404858.30/s
(n=400)
method: 22 wallclock secs (20.98 usr + 0.00 sys = 20.98 CPU) @ 190657.77/s
(n=400)
pkgmethod: 35 wallclock secs (35.59 usr + 0.00 sys = 35.59 CPU) @ 112391.12/s
(n=400)
bench.pl:
#!/usr/bin/perl -w
use strict;
use Benchmark;
my $meth = new Foo;
my $cref = sub { my $data = shift; return 1 };
timethese(400, { 'method' = sub { return $meth-bar },
'closure' = sub { return $cref-() },
'pkgmethod' = sub { return Foo-bar }});
package Foo;
sub new {
return bless {}, shift;
}
sub bar {
my $self = shift;
my $data = shift;
return 1;
}
--
Chip Turner [EMAIL PROTECTED]
RHN Web Engineer
Re: Appending Sessionid to all the urls
Stuart Frew [EMAIL PROTECTED] writes: The user is using the system to process client A. The cookie contains stateful information including the client ID. They then open an new browser window, and lookup client B, recieving a new session ID with new state information, including the client ID. The user then submits the form to the server. The server then recives the one and only cookie with a session ID in it. But is it for Client A or Client B? 50-50 chance of updating the right row. Not good. Session information should be used for the most minimal set of data possible. Often times sessions get used where pnotes would be better, or where hidden form variables would be better. The situation you describe is unlikely and avoidable if you set out with the idea in mind to not put anything in a session that absolutely doesn't need to be there; use your database to store information if you need to and if at all feasible. The problem you mention is real, but in real world scenarios it can typically be avoided. About the only thing you can't avoid is if the user wants to log in simultaneously as two different users. Most normal users don't want to do that, though :) Chip -- Chip Turner [EMAIL PROTECTED] RHN Web Engineer
Re: Problem running CGI Script
Garima Kishore wrote: Hi, Assuming I have configured Apache server for running CGI scripts on the Linux platform , I get an error when I type the URL http://MYMACHINENO:8080/cgi-bin/.PLX PROGRAM on the browser ERROR:The requested item could not be loaded by the proxy.Operation timed out. This type of error occurs when the program goes into a loop or hangs and the browser is left waiting until it gets fed up and times out. Your URL looks very strange... Is your program really called .PLX? What is the word PROGRAM doing on its own in the URL - is it meant to be an argument? Please check a few things: - Does your program run properly from the command line? - If you want to send arguments, use the correct CGI syntax, e.g. http://mymachine:8080/cgi-bin/my_prog?arg1=bananaarg2=kiwi i.e. - the argument list is joined to the program name with a ? - arguments and values are joined with a = - extra argument/value pairs are joined with a Best regards, Owen Boyle.
macintosh osX - mod_perl install problems
hello this might be mac-specific ... can anyone help with this - ive looked around on the net but cant seem to find an answer anywhere i have compiled apache 1_3.20 and perl 5.6.1 problemless. i have also installed the nesecary modules before mod_perl and now want to build mod_perl itself. im aware of the head/HEAD problem that comes with LWP on mac osX and have therefore copied a binary head that ken williams sent me into /usr/bin and moved the lwp head into /usr/local/bin. below follows an exerpt from the shell thanks allan [localhost:/Applications/mod_perl-1.25] aju% sudo perl makefile.pl everything=1 apache_prefix=/usr/local/apache Configure mod_perl with ../apache_1.3.20/src ? [y] y Shall I build httpd in ../apache_1.3.20/src for you? [y] y Appending mod_perl to src/Configuration Unknown option: 1 Usage: head [-options] url... -m method use method for the request (default is 'HEAD') etc. etc. ... Using config file: /Applications/mod_perl-1.25/src/Configuration Creating Makefile + configured for Darwin platform + setting C compiler to cc + setting C pre-processor to cc -E -traditional-cpp + checking for system header files + adding selected modules Usage: head [-options] url... -m method use method for the request (default is 'HEAD') etc. etc. ... + checking sizeof various data types + doing sanity check on compiler and options Creating Makefile in support Creating Makefile in regex Creating Makefile in os/unix Creating Makefile in ap Creating Makefile in main Creating Makefile in lib/expat-lite Creating Makefile in modules/standard EXTRA_CFLAGS: -DDARWIN -DUSE_HSREGEX -DUSE_EXPAT -I$(SRCDIR)/lib/expat-lite -DNO_DL_NEEDED PerlDispatchHandler.disabled (enable with PERL_DISPATCH=1) PerlChildInitHandlerenabled PerlChildExitHandlerenabled PerlPostReadRequestHandler..disabled (enable with PERL_POST_READ_REQUEST=1) PerlTransHandlerdisabled (enable with PERL_TRANS=1) PerlHeaderParserHandler.disabled (enable with PERL_HEADER_PARSER=1) PerlAccessHandler...disabled (enable with PERL_ACCESS=1) PerlAuthenHandler...disabled (enable with PERL_AUTHEN=1) PerlAuthzHandlerdisabled (enable with PERL_AUTHZ=1) PerlTypeHandler.disabled (enable with PERL_TYPE=1) PerlFixupHandlerdisabled (enable with PERL_FIXUP=1) PerlHandler.enabled PerlLogHandler..disabled (enable with PERL_LOG=1) PerlInitHandler.disabled (enable with PERL_INIT=1) PerlCleanupHandler..disabled (enable with PERL_CLEANUP=1) PerlRestartHandler..disabled (enable with PERL_RESTART=1) PerlStackedHandlers.disabled (enable with PERL_STACKED_HANDLERS=1) PerlMethodHandlers..disabled (enable with PERL_METHOD_HANDLERS=1) PerlDirectiveHandlers...disabled (enable with PERL_DIRECTIVE_HANDLERS=1) PerlTableApidisabled (enable with PERL_TABLE_API=1) PerlLogApi..disabled (enable with PERL_LOG_API=1) PerlUriApi..disabled (enable with PERL_URI_API=1) PerlUtilApi.disabled (enable with PERL_UTIL_API=1) PerlFileApi.disabled (enable with PERL_FILE_API=1) PerlConnectionApi...enabled PerlServerApi...enabled PerlSectionsdisabled (enable with PERL_SECTIONS=1) PerlSSI.disabled (enable with PERL_SSI=1) Will run tests as User: 'nobody' Group: 'wheel' Checking CGI.pm VERSION..ok Checking for LWP::UserAgent..ok Checking for HTML::HeadParserok Checking if your kit is complete... Looks good 'APACHE_PREFIX' is not a known MakeMaker parameter name. 'EVERYTHING' is not a known MakeMaker parameter name. Writing Makefile for Apache Writing Makefile for Apache::Connection Writing Makefile for Apache::Constants Writing Makefile for Apache::File Writing Makefile for Apache::Leak Writing Makefile for Apache::Log Writing Makefile for Apache::ModuleConfig Writing Makefile for Apache::PerlRunXS Writing Makefile for Apache::Server Writing Makefile for Apache::Symbol Writing Makefile for Apache::Table Writing Makefile for Apache::URI Writing Makefile for Apache::Util Writing Makefile for mod_perl [localhost:/Applications/mod_perl-1.25] aju% sudo make (cd ../apache_1.3.20/src PERL5LIB=/Applications/mod_perl-1.25/lib env LD_RUN_PATH=/System/Library/Perl/darwin/CORE make CC=cc;) === regex cc -I. -I../os/unix -I../include -DDARWIN -DUSE_HSREGEX -DUSE_EXPAT -I../lib/expat-lite -DNO_DL_NEEDED -g -pipe -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing -I/usr/local/include -DMOD_PERL -DPOSIX_MISTAKE -c -o regcomp.o regcomp.c etc. etc. ... /usr/bin/ld: Undefined symbols: _actions_module _include_module _log_config_module make[1]: *** [target_static] Error 1 make: *** [apache_httpd] Error 2 [localhost:/Applications/mod_perl-1.25] aju%
Re: ANNOUNCE: Soup (0.2) (fwd)
On Thu, 24 May 2001, brian moseley wrote: so who's doing the perl wrappers? /me raises a hand. Since it uses libxml, I might as well have a look. -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: Real Widgets and Template Languages
On 25 May 2001, Chip Turner wrote:
My only objection to this (as I stated in another email)
is that it leaves things largely unspecified. It's
similar to the old perl problem of passing big hashes
around; you assume the data is there, but there's no
real way to find out without checking keys and so forth.
A simple $foo-isa('Widget::CGIData') can ensure that
what you're talking to is at least derived from the
right thing. Just because perl would let you call
methods on a class not derived from a standard base
doesn't mean it's necessarily appropriate. An abstract
base class offers little overhead (especially if you
override all of the methods) while still giving that
little bit of insurance about just what you've been
passed. In a library that conceivably could be used by
a number of people, such discipline would probably be a
nice thing, even if it didn't actually buy anything in
terms of performance or features.
so the only reason you'd provide a superclass is to be able
to do an isa check? in what circumstances do you use this
kind of check? do you apply it to every argument in every
method call? what do you do on failure?
i've been wondering how best to specify interfaces (in the
java sense) in perl, whether or not to make them classes.
possible benefits are type checking (as you've noted above)
and verification of the implementation of methods specified
by the interface. altho if i could get benefit #2, i
wouldn't care about #1, cos i just want to be sure that the
implementing class (or one of its ancestors) declares each
of the interface methods. and i want this verification at
compile time, not runtime.
Re: Appending Sessionid to all the urls
On 25 May 2001, Chip Turner wrote: The problem you mention is real, but in real world scenarios it can typically be avoided. About the only thing you can't avoid is if the user wants to log in simultaneously as two different users. Most normal users don't want to do that, though :) only if you have a one to one relationship between client (browser) session and authenticated user. this is not mandatory if, as you point out, urls or form fields are used to transmit the user's id. other than this scenario, which i've never chosen to support, i've never met a piece of session-scoped data that needed to be propagated back to the client besides the client's session id.
Re: Real Widgets and Template Languages
brian moseley [EMAIL PROTECTED] writes:
My only objection to this (as I stated in another email) is that
it leaves things largely unspecified. It's similar to the old
perl problem of passing big hashes around; you assume the data is
there, but there's no real way to find out without checking keys
and so forth. A simple $foo-isa('Widget::CGIData') can ensure
that what you're talking to is at least derived from the right
thing. Just because perl would let you call methods on a class
not derived from a standard base doesn't mean it's necessarily
appropriate. An abstract base class offers little overhead
(especially if you override all of the methods) while still giving
that little bit of insurance about just what you've been passed.
In a library that conceivably could be used by a number of people,
such discipline would probably be a nice thing, even if it didn't
actually buy anything in terms of performance or features.
so the only reason you'd provide a superclass is to be able to do an
isa check? in what circumstances do you use this kind of check? do
you apply it to every argument in every method call? what do you do
on failure?
Well, not entirely. It's like the difference between using symbolic
references and not using symbolic references. Sure, they work, and
can be powerful, but they can also be obfuscating and a little
obscure. I don't like tossing objects around and expecting them to
adhere to some unknown interface that they aren't derived from. The
only real difference at the code layer is -isa, but that's not a
large benefit; instead, it's at the design level. Making an abstract
base class is very simple, and there's no performance overhead for a
class to derive from it if it implements all of its own methods (and
one could argue if there -is- common code that can be implemented in
non-abstract base methods then there is even more benefit in having an
abstract base class).
Basically it's enforcing a tiny bit of type data in an otherwise
more or less typeless world.
Code is cleaner if you can say the nth parameter is derived from the
base class Foo::Bar as opposed to the nth parameter is an object
that must support the baz, blah, foop, and fitz methods that accept
parameters in the following way...
i've been wondering how best to specify interfaces (in the java
sense) in perl, whether or not to make them classes. possible
benefits are type checking (as you've noted above) and verification
of the implementation of methods specified by the interface. altho
if i could get benefit #2, i wouldn't care about #1, cos i just want
to be sure that the implementing class (or one of its ancestors)
declares each of the interface methods. and i want this verification
at compile time, not runtime.
Well, you could always do something like:
my Foo::Bar $x = shift;
This doesn't really gain anything now, but it makes things a bit
clearer what exactly is going on. Future perl's may optimize this
(right now, if I recall, it only optimizes in the case of
pseudohashes).
Sadly, you'll never really be able to get compile time type
verification in perl (at least, in perl as it stands today). Even the
above syntax is only a promise to perl for possible optimizations and
not a request for perl to enforce the type of whatever shift returns.
Chip
--
Chip Turner [EMAIL PROTECTED]
RHN Web Engineer
These are probably simple questions.
If I upgraded Perl, do I need to recompile mod_perl? And if I have multiple Perls on a machine (eg 5.6.0 and 5.6.1. maybe in some non-standard directories), how can I tell mod_perl which one to use? Where is the place to check for Perl's config such as @INC? Thanks in advance. Bird Lei
Re: Real Widgets and Template Languages
On 25 May 2001, Chip Turner wrote: Code is cleaner if you can say the nth parameter is derived from the base class Foo::Bar as opposed to the nth parameter is an object that must support the baz, blah, foop, and fitz methods that accept parameters in the following way... you can certainly say the nth parameter implements interface Foo::Bar, and provide Foo/Bar.pod that describes the interface, and get the exact same benefit. i question the wisdom of relying on a code-level inheritance usage to communicate class relationships. isn't that why we use class diagrams and pod?
Re: Real Widgets and Template Languages
On 25 May 2001, Chip Turner wrote:
brian moseley [EMAIL PROTECTED] writes:
you can certainly say the nth parameter implements
interface Foo::Bar, and provide Foo/Bar.pod that describes
the interface, and get the exact same benefit.
Of course. But you lose nothing by actually making it an ISA
relationship; you don't even lose performance. Plus you could do
something like this:
sub foo {
my $self = shift;
my $bar = shift;
$self-die_because_of_bad_bar_parameter
if $DEBUG and not $bar-isa('SomeBase::Class');
...
}
You can have the checks in during development, and pull during
production. It's not 100% efficient, but it's pretty close. With
some use constant magic, you may even be able to get the compiler to
optimize away the entire line at compile time, resulting not even in a
check on the value of $DEBUG in production environments.
which is true only if it's:
use constant DEBUG = 1;
and not:
$DEBUG = 1;
Basically you should be able to turn the development checking at compile
time for the whole project via startup.pl:
use My::Init qw(PRODUCTION);
vs.
use My::Init qw(DEVELOPMENT);
where the My::Init::import() method will load and compile all the modules
that are going to be used, but only after My::Config::DEBUG constant is
either set to 0 or 1.
So you don't have to remember to manually modify every module, in fact
none of them. startup.pl time resolution will make things really flexible.
On the other hand under mod_cgi this can be done in the first BEGIN block
of every script that you use (but then it's cumbersome, since you have to
modify all the scripts all the time, and possibly conflict with CVS) but
hey, we are on the mod_perl list :)
To conclude, if you make all your checkings/validations only in debug
version it doesn't matter how fast or slow they are. I think what matters
here is the clearness of the code.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Real Widgets and Template Languages
Stas Bekman [EMAIL PROTECTED] writes: You can have the checks in during development, and pull during production. It's not 100% efficient, but it's pretty close. With some use constant magic, you may even be able to get the compiler to optimize away the entire line at compile time, resulting not even in a check on the value of $DEBUG in production environments. which is true only if it's: use constant DEBUG = 1; and not: $DEBUG = 1; Right; hence my veiled reference to 'use constant' magic :) Basically you should be able to turn the development checking at compile time for the whole project via startup.pl: use My::Init qw(PRODUCTION); vs. use My::Init qw(DEVELOPMENT); I like this method of turning debug on and off. Hadn't seen this novel method, but it has a nice feel to it. To conclude, if you make all your checkings/validations only in debug version it doesn't matter how fast or slow they are. I think what matters here is the clearness of the code. I agree 100%. Chip -- Chip Turner [EMAIL PROTECTED] RHN Web Engineer
RE: compilation: libperl.a
All, Stas is absolutely right; the steps on the guide are fine. I had seen an error doing compile but mistook it for a warning; therefore, the compile never finished. So if you ever notice that the libperl.a file is missing, it's a sure sign that your apache compile is not completing. Have a great day. -Chethan -- Chethan Pandarinath Senior, Computer Engineering Science, Technology and Society NC State University (919) 754-0325 | [EMAIL PROTECTED] | AIM: chetpan http://pandarinath.com -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 12:02 AM To: Chethan Pandarinath Cc: [EMAIL PROTECTED] Subject: Re: compilation: libperl.a On Thu, 24 May 2001, Chethan Pandarinath wrote: Hi all, I've been trying to compile apache with mod_perl and mod_php support. I've been following the instructions from the mod_perl Guide [http://perl.apache.org/guide/install.html#mod_perl_and_mod_php] (and just assuming that it's similar for php3 and php4). I haven't been able to get mod_perl to compile in (ie make test fails for mod_perl, server never warms up). One thing that's confused me is the line in the configuration of Apache right before the build: --activate-module=src/modules/perl/libperl.a I've compiled php4 and mod_perl following these notes two days ago for the book: Are you sure you did follow the steps exactly? ( you have adjust php3 to php4 for the latest version)/ Unfortunately even after I make mod_perl, I don't get any libperl.a file in that directory. The closest thing I get is a libperl.module file. Does this sound familiar to anyone? Any ideas what I'm doing wrong? Sorry if this is an old topic; I searched the archives but couldn't find anything helpful. it's on topic. Here is a fresh scenario cleaned up for the book, but I think that it's pretty much the same as in the guide: =head2 Installing mod_perl with mod_php The following is a simple installation scenario of a combination mod_perl and mod_php build for the Apache server. Since we aren't going to configure custom installation directory, Apache will use the default I/usr/local/apache directory. =over =item 1 Download the latest stable source releases: Apache: http://www.apache.org/dist/httpd/ mod_perl: http://perl.apache.org/dist/ PHP: http://www.php.net/downloads.php =item 1 Un-pack: panic% tar xvzf mod_perl-x.xx panic% tar xvzf apache_x.x.x.tar.gz panic% tar xvzf php-x.x.xx.tar.gz =item 1 Configure Apache. panic% cd apache_x.x.xx panic% ./configure =item 1 Build mod_perl: panic% cd ../mod_perl-x.xx panic% perl Makefile.PL APACHE_SRC=../apache_x.x.xx/src NO_HTTPD=1 \ USE_APACI=1 PREP_HTTPD=1 EVERYTHING=1 panic% make =item 1 Build mod_php: panic% cd ../php-x.x.xx panic% ./configure --with-apache=../apache_x.x.xx \ --with-mysql --enable-track-vars panic% make panic# make install [F] mod_php doesn't come with Imake test suit, so we don't run it [/F] =item 1 Reconfigure Apache to use mod_perl and PHP and build it: panic% cd ../apache_x.x.xx panic% ./configure \ --activate-module=src/modules/perl/libperl.a \ --activate-module=src/modules/php4/libphp4.a panic% make [F] If you are building PHP3, use Iphp3/libphp3.a. [/F] =item 1 Test and install mod_perl panic% cd ../mod_perl-x.xx panic% make test panic# make install. =item 1 Complete the Apache installation. panic# cd ../apache_x.x.xx panic# make install =back Now when you start the server: panic# /usr/local/apache/bin/apachectl start you should see something like this in I/usr/local/apache/logs/error_log: [Fri May 18 11:10:31 2001] [notice] Apache/1.3.19 (Unix) PHP/4.0.5 mod_perl/1.25 configured -- resuming normal operations _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Getting the wrong URL
On 24 May 2001, [EMAIL PROTECTED] wrote: .. I have a web site where *everything* is mod_perl handlers. The problem that I'm seeing is that I will go to the url http://hostname/foo and I get the content from http://hostname/bar This seems to be happening when there is a server error of some variety, and from then on, until a server restart, users are just getting whatever the last thing was that that Apache child served. I have not been able to completely verify this, but I am consistently getting the same (wrong) content from a particular child, so apparently the particular child just keeps giving me whatever it served the last time. On Fri, 25 May 2001 10:31:09 +0800 (SGT), Stas Bekman said: looks like http://perl.apache.org/guide/porting.html#Exposing_Apache_Registry_secret http://perl.apache.org/guide/porting.html#Sometimes_it_Works_Sometimes_it We're not doing anything with Apache::Registry. Everything is with Perl handlers. It always seemed to me that the problems described at those locations were specific to Apache::Registry. So you're saying that if a Perl handler module falls over for some reason, that child will continue serving the last content it served, forever? This strikes me as a bad thing. Anyways, all of the possible reasons listed there are not, as far as we can tell, going on in our code. Everything is 100% OO, nothing is global or exported, and everything uses strict and warnings. Perhaps I'm misunderstanding when things actually pass out of scope in a mod_perl environment. Since almost all of the availble documentation seems to be about using Apache::Registry, rather than about writing handlers, it's not always clear whether things like this necessarily translate to both. -- Director of Application Development The Creative Group http://products.cre8tivegroup.com/
Similiar to getting the wrong url!
On our site we have a page that does a search into a postgress database and then displays the results. When the site was running on redhat 6.2 it would occasionaly (1 out of 10) display false results. Since we have moved the site to a redhat 7.0 with the same perl and mod-perl as redhat 6.2 the search missed 50% of the time. any ideas?
Re: Getting the wrong URL
On 25 May 2001, [EMAIL PROTECTED] wrote: On 24 May 2001, [EMAIL PROTECTED] wrote: .. I have a web site where *everything* is mod_perl handlers. The problem that I'm seeing is that I will go to the url http://hostname/foo and I get the content from http://hostname/bar This seems to be happening when there is a server error of some variety, and from then on, until a server restart, users are just getting whatever the last thing was that that Apache child served. I have not been able to completely verify this, but I am consistently getting the same (wrong) content from a particular child, so apparently the particular child just keeps giving me whatever it served the last time. On Fri, 25 May 2001 10:31:09 +0800 (SGT), Stas Bekman said: looks like http://perl.apache.org/guide/porting.html#Exposing_Apache_Registry_secret http://perl.apache.org/guide/porting.html#Sometimes_it_Works_Sometimes_it We're not doing anything with Apache::Registry. Everything is with Perl handlers. It always seemed to me that the problems described at those locations were specific to Apache::Registry. So you're saying that if a Perl handler module falls over for some reason, that child will continue serving the last content it served, forever? This strikes me as a bad thing. It's quite possible if you happen to create closures in your dispatch handler for example. It's a bad thing :) Anyways, all of the possible reasons listed there are not, as far as we can tell, going on in our code. Everything is 100% OO, nothing is global or exported, and everything uses strict and warnings. Perhaps I'm misunderstanding when things actually pass out of scope in a mod_perl environment. Since almost all of the availble documentation seems to be about using Apache::Registry, rather than about writing handlers, it's not always clear whether things like this necessarily translate to both. I'd switch to a single server mode first thing first. Do you see the same behavior with httpd -X? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Similiar to getting the wrong url!
On Fri, 25 May 2001, Jean Louis Girard wrote: On our site we have a page that does a search into a postgress database and then displays the results. When the site was running on redhat 6.2 it would occasionaly (1 out of 10) display false results. Since we have moved the site to a redhat 7.0 with the same perl and mod-perl as redhat 6.2 the search missed 50% of the time. any ideas? httpd -X and code isolation/small test reproducing technique first. print()/warn() and debugger next (still running under -X). There is a reason for me sending you to read about Apache::Registry problem. It's just an example of what can go wrong with your code. read the registry explanation, understand why you have to switch to -X, then do that and you will find your problem. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Apache::Session / No-Cookie-Tracking
I want to be able to track visitors without the use of cookies. I don't want to rely on IP address, because people behind proxies and firewalls seem to have the same IP address. I don't want to rely on a session ID variable being always present in the URL, in case the window gets closed or changed. Now, two questions: 1) Will Apache::Session provide an environment variable like HTTP_USER_AGENT that will contain an identifier that will always be consistent for that specific user, despite proxies and firewalls, and despite the changing/closing of windows? 2) If not, does anyone know of a good way to do this? Jonathan
Re: Apache::Session / No-Cookie-Tracking
JH I want to be able to track visitors without the use of cookies. JH I don't want to rely on IP address, because people behind proxies and JH firewalls seem to have the same IP address. JH I don't want to rely on a session ID variable being always present in the JH URL, in case the window gets closed or changed. JH Now, two questions: JH 1) Will Apache::Session provide an environment variable like JH HTTP_USER_AGENT that will contain an identifier that will always JH be consistent for that specific user, despite proxies and JH firewalls, and despite the changing/closing of windows? JH 2) If not, does anyone know of a good way to do this? Do you believe in magic? :) The only way to track visitors is either: 1) use cookies 2) use session ID variable in URI and/or hidden field with session ID in forms 3) use IPs (which is bad because it is completely broken approach) 4) use HTTP authorization (which is not always convenient because requires user registration) Apache::Session can only create persistent storage of session data. Each session data identified by some session ID. This ID should be taken from somewhere (see above). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re: Handling the 'User pressed Stop button' case - not working
On Fri, 25 May 2001, Matthew Darwin wrote: I've been following the documentation at http://www.perldoc.com/cpan/Apache/Example.html#Handling%20the%20'User%20pressed%20Stop%20button'%20case I've written a test perl module that implements the code to handle the case when the user presses 'stop'. When I do GET http://localhost:81/nm/xxx then press ^C, everything works as expected. However, when I do GET http://localhost:80/nm/xxx which involves going through a second apache server (http://perl.apache.org/tuning/#USING_ProxyPass_WITH_TWO_SERVERS), pressing ^C never terminates the web request. Is the first Apache not closing the socket for the second Apache? Has anybody run into this before? I'm using Linux 2.2 with Apache/1.3.19 (Unix) mod_perl/1.25 Configuration details available upon request. You right. It seems that mod_proxy won't abort on SIGPIPE. 1. mod_proxy won't notice any problem since it buffers your output from mod_perl, until the buffer is full or the connection is closed. 2. if you change \0 with \0 x 2**14 (16k), it detects it immediately but doesn't abort the connection and keeps on reading the output from mod_perl server. Observe the output of strace: alarm(300) = 300 read(4, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 8192) = 8192 alarm(300) = 300 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 8192) = -1 EPIPE (Broken pipe) --- SIGPIPE (Broken pipe) --- alarm(300) = 300 read(4, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 8192) = 8192 alarm(300) = 299 so mod_perl never learns that the connection was aborted. Apache doesn't catch SIGPIPE and mod_proxy doesn't do anything by itself. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
FW: Apache::Session / No-Cookie-Tracking
Sure - I believe in magic, depending on your definition of it. I KNOW there's a 4th method, because I've seen it work. There is an e-commerce web site which uses an outside cart programmed in CGI (Perl?). The original web site passes no identifying marks such as the session ID through the URL or through the form's submit button to add an item to the cart. I know, because I designed and created the web site. However, when the visitors hit the submit button, they are taken to another program/website containing their shopping basket filled with their items. I have figured out that it relies somewhat on the IP address, but not completely, because I have tested it behind the firewall and the other computer behind the firewall with me does not share the same basket. Once I am at that screen (viewing the contents of my cart on the program), there are other links which contain a session ID of sorts carried via the URL. The thing that is driving my head crazy is how they identify the user in the first place to create the links with the session ID. I accidentally caught them during testing or something and got a variable on the URL line. (I substituted the domain name - it's not really cart.com) http://www.cart.com/cgi-bin/cart.cgi?cartidnum=208.144.33.190T990806951R5848 E cartidnum seems to be: $IP-Address + T + Unix-TimeStamp + R + Unknown number + E By the way, the session only seems to active until the browser completely shuts down. Any ideas? If I could identify my users on another site without using cookies at all, that would be fantastic! Jonathan -Original Message- From: Ilya Martynov [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 9:02 AM To: Jonathan Hilgeman Cc: '[EMAIL PROTECTED]' Subject: Re: Apache::Session / No-Cookie-Tracking JH I want to be able to track visitors without the use of cookies. JH I don't want to rely on IP address, because people behind proxies and JH firewalls seem to have the same IP address. JH I don't want to rely on a session ID variable being always present in the JH URL, in case the window gets closed or changed. JH Now, two questions: JH 1) Will Apache::Session provide an environment variable like JH HTTP_USER_AGENT that will contain an identifier that will always JH be consistent for that specific user, despite proxies and JH firewalls, and despite the changing/closing of windows? JH 2) If not, does anyone know of a good way to do this? Do you believe in magic? :) The only way to track visitors is either: 1) use cookies 2) use session ID variable in URI and/or hidden field with session ID in forms 3) use IPs (which is bad because it is completely broken approach) 4) use HTTP authorization (which is not always convenient because requires user registration) Apache::Session can only create persistent storage of session data. Each session data identified by some session ID. This ID should be taken from somewhere (see above). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re: Apache::Session / No-Cookie-Tracking
Sure - I believe in magic, depending on your definition of it. I KNOW there's a 4th method, because I've seen it work. There is an e-commerce web site which uses an outside cart programmed in CGI (Perl?). The original web site passes no identifying marks such as the session ID through the URL or through the form's submit button to add an item to the cart. I know, because I designed and created the web site. However, when the visitors hit the submit button, they are taken to another program/website containing their shopping basket filled with their items. I have figured out that it relies somewhat on the IP address, but not completely, because I have tested it behind the firewall and the other computer behind the firewall with me does not share the same basket. Once I am at that screen (viewing the contents of my cart on the program), there are other links which contain a session ID of sorts carried via the URL. The thing that is driving my head crazy is how they identify the user in the first place to create the links with the session ID. I accidentally caught them during testing or something and got a variable on the URL line. (I substituted the domain name - it's not really cart.com) http://www.cart.com/cgi-bin/cart.cgi?cartidnum=208.144.33.190T990806951R5848 E cartidnum seems to be: $IP-Address + T + Unix-TimeStamp + R + Unknown number + E By the way, the session only seems to active until the browser completely shuts down. Any ideas? Sure sounds like a cookie to me. What makes you think it isn't one? Or else they just don't care who you are until you hit the shopping cart, and then they keep your identity with URLs and hidden form fields. - Perrin
Re: FW: Apache::Session / No-Cookie-Tracking
Jonathan Hilgeman [EMAIL PROTECTED] wrote: [snip] I accidentally caught them during testing or something and got a variable on the URL line. (I substituted the domain name - it's not really cart.com) http://www.cart.com/cgi-bin/cart.cgi?cartidnum=208.144.33.190T990806951R5848 E cartidnum seems to be: $IP-Address + T + Unix-TimeStamp + R + Unknown number + E By the way, the session only seems to active until the browser completely shuts down. Any ideas? If I could identify my users on another site without using cookies at all, that would be fantastic! Be careful with using too much magic. I recently tested/evaluated a product to provide a web interface for email. It appears that it uses a combination IP address and URL to track authenticated users. For example, if I authenticated as foo from 192.168.0.4, then as long as I was coming from 192.168.0.4, I could read foo's email, even if I was someone else logged into the machine. The proper URL would be of the form http://192.168.0.10/foo (if 192.168.0.10 were the server). While it is nice to assume one person per IP address, there are many cases when this is not true. In the product I evaluated, guessing the proper URL to read someone else's email was trivial. Going through an SSL proxy didn't mask the behavior, just required the use of openssl's client. In the example you give, the timestamp and unknown number may make it more difficult to guess the proper information. This is a good thing. Without some information passing between the client and server that is only known to them, it is too easy to spoof the client and access a session unauthorized. There is also no way to distinguish two clients on the same machine, especially if they are the same application. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
RE: Apache::Session / No-Cookie-Tracking
The feeling of magic only lasts until you know how it's done, and I have seen the light. What happens is that they use a per-session cookie, so it doesn't appear in my temp folder. But, if per-session cookies are disabled, then it relies on the IP address. I guess that is better than just one method, but I think I may use the same method, but base the no-cookie method on both IP address AND HTTP_USER_AGENT to try to make things more unique. Jonathan -Original Message- From: Ilya Martynov [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 9:35 AM To: Jonathan Hilgeman Subject: Re: Apache::Session / No-Cookie-Tracking JH Sure - I believe in magic, depending on your definition of it. I KNOW JH there's a 4th method, because I've seen it work. There is an e-commerce web JH site which uses an outside cart programmed in CGI (Perl?). The original web JH site passes no identifying marks such as the session ID through the URL or JH through the form's submit button to add an item to the cart. I know, because JH I designed and created the web site. JH [..skip..] Interesting. If you will say me url of your web site where you are using this outside cart probably I'll find how they do tracking. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Concepts of Unique Tracking
Okay, after I think about it, there must be a way to identify a unique user, even if they are behind a firewall. Let's run through this process: 1) Person behind the firewall sends out a request to a web server. 2) The firewall intercepts that request, masks the person's IP address and lets the request keep going out. 3) The web server receives the request and sends back packets of data to the IP of the user, which is really the IP of the firewall now. 4) The firewall receives the packets of data first, but now must send those data packets to someone inside the firewall. 5) The packets of data MUST have some unique identifier to let the firewall know who requested the data in the first place. Now, I'm assuming that Apache has full access to these incoming packets. Therefore, they must also have access to this invisible identifier. Is it possible to extract that identifier somehow by tinkering with Apache? Jonathan
Re: Concepts of Unique Tracking
Jonathan Hilgeman [EMAIL PROTECTED] wrote: Okay, after I think about it, there must be a way to identify a unique user, even if they are behind a firewall. Let's run through this process: 1) Person behind the firewall sends out a request to a web server. 2) The firewall intercepts that request, masks the person's IP address and lets the request keep going out. 3) The web server receives the request and sends back packets of data to the IP of the user, which is really the IP of the firewall now. 4) The firewall receives the packets of data first, but now must send those data packets to someone inside the firewall. 5) The packets of data MUST have some unique identifier to let the firewall know who requested the data in the first place. Now, I'm assuming that Apache has full access to these incoming packets. Therefore, they must also have access to this invisible identifier. Is it possible to extract that identifier somehow by tinkering with Apache? No. What happens is more like this: (1) Browser opens socket for connecting to remote server. This assigns a unique identifier to the TCP connection - IP + socket on client side. (2) Browser connects to remote server, which actually ends up connecting to firewall. Firewall has a unique number on its side - its IP + socket (80 or 443 most likely). (3) Firewall opens socket for connecting to remote server. This assigns a unique identifier to the TCP connection - firewall's public IP + socket. Firewall remembers this and will transfer any data coming from client to this connection, and any data from this connection to the client. This is part of what is meant by a firewall which saves state information. All the information needed to connect the client and server via the firewall is kept within the firewall. Neither the client or server need be aware of any of it, nor, afaik, can they be aware of it without putting a http proxy on the firewall. The server is seeing the firewall's IP and socket, not the actual client's. This will change with each connection made, which will happen if the keepalive timeout happens. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
Re: Concepts of Unique Tracking
Jonathan Hilgeman wrote: Now, I'm assuming that Apache has full access to these incoming packets. Therefore, they must also have access to this invisible identifier. Is it possible to extract that identifier somehow by tinkering with Apache? The only thing that you can access from the webserver side is the REMOTE_ADDR and REMOTE_PORT. IP masquarding is handled only by the firewall that is doing the masquarding: the web server and browser have no idea that this is happening. The firewall has a table that keeps track of open TCP connections, so that when it receives data on the outside port (e.g. 61172) it knows to rewrite the packet and send it off back to the inside client (e.g. 192.168.1.42:49372) that created the initial TCP connection. This is one of primary reasons that cookies exist. -- Regards, Wim Kerkhoff, Software Engineer Merilus, Inc. -|- http://www.merilus.com Email: [EMAIL PROTECTED]
RE: Concepts of Unique Tracking
Actually, I had come up with a similar idea after I sent that one off. My idea was that packets had packet identifiers in their header or footer, and the packet identifiers were stored in the firewall and referenced to the computer inside the firewall, so whenever packets with that identifier came back, the firewall knew which computer to send it to. Oh well. What about client-specific information available in Javascript, like screen resolution, size, etc...? Can that be accessed by tinkering with Apache a bit, or is it something only available because of the browser, since Javascript is dependent on the browser? Jonathan -Original Message- From: Wim Kerkhoff [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 10:15 AM To: Jonathan Hilgeman Cc: '[EMAIL PROTECTED]' Subject: Re: Concepts of Unique Tracking Jonathan Hilgeman wrote: Now, I'm assuming that Apache has full access to these incoming packets. Therefore, they must also have access to this invisible identifier. Is it possible to extract that identifier somehow by tinkering with Apache? The only thing that you can access from the webserver side is the REMOTE_ADDR and REMOTE_PORT. IP masquarding is handled only by the firewall that is doing the masquarding: the web server and browser have no idea that this is happening. The firewall has a table that keeps track of open TCP connections, so that when it receives data on the outside port (e.g. 61172) it knows to rewrite the packet and send it off back to the inside client (e.g. 192.168.1.42:49372) that created the initial TCP connection. This is one of primary reasons that cookies exist. -- Regards, Wim Kerkhoff, Software Engineer Merilus, Inc. -|- http://www.merilus.com Email: [EMAIL PROTECTED]
RE: Concepts of Unique Tracking
Actually, someone suggested HTTP authorization - does that require a cookie to work? Or after they are authorized, it simply keeps the session open in the browser...? Jonathan -Original Message- From: Brian Reichert [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 10:20 AM To: Jonathan Hilgeman Cc: '[EMAIL PROTECTED]' Subject: Re: Concepts of Unique Tracking On Fri, May 25, 2001 at 10:03:04AM -0700, Jonathan Hilgeman wrote: Now, I'm assuming that Apache has full access to these incoming packets. Therefore, they must also have access to this invisible identifier. Is it possible to extract that identifier somehow by tinkering with Apache? Most NAT implemetations keep a hash of destination ports - internal IP. To wit: 1) Person behind the firewall sends out a request to a web server. Person _really_ establishes an outgoing TCP session with his NAT box. The NAT box notes his internal_IP:dest_port, sets up an outgoing TCP session to web server, notes it's own source port for that leg. 4) The firewall receives the packets of data first, but now must send those data packets to someone inside the firewall. Returning packets from the webserver come to that source port, NAT box looks up hash of: external_IP:source_port - internal_IP:dest_port, and hands the packet in. 5) The packets of data MUST have some unique identifier to let the firewall That would be the source port of the NAT box's outgoing connection. But: - each outgoing TCP connection from the internal host will use a different source port. - the request your web server is receiving may actaully (likely) be coming from a web cache somewhere. Jonathan -- Brian 'you Bastard' Reichert[EMAIL PROTECTED] 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path
Re: Concepts of Unique Tracking
Jonathan Hilgeman wrote: What about client-specific information available in Javascript, like screen resolution, size, etc...? Can that be accessed by tinkering with Apache a bit, or is it something only available because of the browser, since Javascript is dependent on the browser? I briefly thought about suggesting something like that, or with combination with the other headers that get sent in the HTTP request for language, encoding, etc. However, think of the situations such as computer labs, internet cafes, etc, where all computers are identical in every aspect, with the exact same version of the browser, hard coded screen resolutions (e.g. 800x600), etc, that the user can not change. -- Regards, Wim Kerkhoff, Software Engineer Merilus, Inc. -|- http://www.merilus.com Email: [EMAIL PROTECTED]
[Patch] Apache-dso_module()
I know I posted this patch a while ago, but I am looking thru a few patches
I have and I thought I might re-post this one along with the rest
This module allows one to do
Apache-dso_module('module_name.c') and it will be true only of the
module in question is present and has been loaded as DSO.
Used to be usefull to me when attempting to work around Perl directives
and mod_perl as DSO/not-DSO (now fixed).
But I figured it could be usefull to others.
--
+---+
| Philippe M. Chiasson [EMAIL PROTECTED]|
| SmartWorker http://www.smartworker.org|
| IM : gozerhbe ICQ : gozer/18279998 |
| 64.8% computer corrupt according to |
| http://www.freespeech.org/ljk/purity.html |
+---+
You're much more likely to be knocked down by a snowball
than by an equivalent number of snowflakes.
-- Larry Wall
perl -e '$$=\${gozer};{$_=unpack(P26,pack(L,$$));/^Just Another Perl
Hacker!\n$/print||$$++redo}'
Index: src/modules/perl/Apache.xs
===
RCS file: /home/cvs/modperl-1/src/modules/perl/Apache.xs,v
retrieving revision 1.121
diff -u -U10 -b -B -I'$Id' -I'$Revision' -r1.121 Apache.xs
--- src/modules/perl/Apache.xs 2001/05/01 17:28:37 1.121
+++ src/modules/perl/Apache.xs 2001/05/02 16:15:58
@@ -476,20 +476,40 @@
CODE:
if((*(SvEND(name) - 2) == '.') (*(SvEND(name) - 1) == 'c'))
RETVAL = find_linked_module(SvPVX(name)) ? 1 : 0;
else
RETVAL = (sv perl_module_is_loaded(SvPVX(name)));
OUTPUT:
RETVAL
+I32
+dso_module(sv,name)
+SV *sv
+SV *name
+
+PREINIT:
+module *mod;
+
+CODE:
+mod = find_linked_module(SvPVX(name));
+if(name mod) {
+RETVAL = (mod-dynamic_load_handle) ? 1 : 0;
+}
+else {
+ XSRETURN_UNDEF;
+}
+
+OUTPUT:
+RETVAL
+
char *
mod_perl_set_opmask(r, sv)
Apache r
SV *sv
void
untaint(...)
PREINIT:
int i;
RE: Apache::Session / No-Cookie-Tracking
use Apache::MindReader; my $future = Apache::MindReader-new( no_mistakes = 1 ); $future-read_mind( no_info_whatsoever = 1 ); my $reliable_unknown_id = $future-track_user(); die Could not figure out user without knowing one single piece of information about them. Weird\n unless ( $reliable_unknown_id ); (Of course your mileage may vary) (For entertainment purposes only) Wink. Wink. Nudge. Nudge. Joe Breeden -Original Message- From: Ilya Martynov [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 11:02 AM To: Jonathan Hilgeman Cc: '[EMAIL PROTECTED]' Subject: Re: Apache::Session / No-Cookie-Tracking JH I want to be able to track visitors without the use of cookies. JH I don't want to rely on IP address, because people behind proxies and JH firewalls seem to have the same IP address. JH I don't want to rely on a session ID variable being always present in the JH URL, in case the window gets closed or changed. JH Now, two questions: JH 1) Will Apache::Session provide an environment variable like JH HTTP_USER_AGENT that will contain an identifier that will always JH be consistent for that specific user, despite proxies and JH firewalls, and despite the changing/closing of windows? JH 2) If not, does anyone know of a good way to do this? Do you believe in magic? :) The only way to track visitors is either: 1) use cookies 2) use session ID variable in URI and/or hidden field with session ID in forms 3) use IPs (which is bad because it is completely broken approach) 4) use HTTP authorization (which is not always convenient because requires user registration) Apache::Session can only create persistent storage of session data. Each session data identified by some session ID. This ID should be taken from somewhere (see above). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
[Patch] apxs location forgotten in MyConfig.pm
When building mod_perl with apxs as a DSO, MyConfig.pm looses track of the
location of apxs. Therefore, when using 3rd parties perl modules that
require some access to Apache information, like Apache::src-new-inc, it
will most likely fail, unless apxs happens to be in a 'standard' location
or in your PATH.
--
+---+
| Philippe M. Chiasson [EMAIL PROTECTED]|
| SmartWorker http://www.smartworker.org|
| IM : gozerhbe ICQ : gozer/18279998 |
| 64.8% computer corrupt according to |
| http://www.freespeech.org/ljk/purity.html |
+---+
You're much more likely to be knocked down by a snowball
than by an equivalent number of snowflakes.
-- Larry Wall
perl -e '$$=\${gozer};{$_=unpack(P26,pack(L,$$));/^Just Another Perl
Hacker!\n$/print||$$++redo}'
Index: Makefile.PL
===
RCS file: /home/cvs/modperl-1/Makefile.PL,v
retrieving revision 1.184
diff -u -U10 -b -B -I'$Id' -I'$Revision' -r1.184 Makefile.PL
--- Makefile.PL 2001/05/01 17:08:25 1.184
+++ Makefile.PL 2001/05/25 17:15:18
@@ -1980,33 +1980,34 @@
sub write_my_config {
my $src = shift;
# preparing and writing Configuration to Apache::MyConfig
my %my_config = %callback_hooks;
my @other_hooks = qw(APACHE_SRC SSL_BASE APXS PERL_USELARGEFILES
PERL_TRACE PERL_DEBUG APACI_ARGS
APACHE_PREFIX DO_HTTPD NO_HTTPD PREP_HTTPD
USE_APACI APACHE_HEADER_INSTALL
- PERL_STATIC_EXTS PERL_SSI PERL_SECTIONS);
+ PERL_STATIC_EXTS PERL_SSI PERL_SECTIONS USE_APXS WITH_APXS);
{
no strict 'refs';
$my_config{$_} = ${$_} for @other_hooks;
}
if ($win32_auto) {
for (qw(APACHE_INC APACHE_LIB MODPERL_INC MODPERL_LIB)) {
$my_config{$_} = $win32_path{$_};
}
}
#need this alias for Apache::src backwards compat
$my_config{'Apache_Src'} = $my_config{'APACHE_SRC'};
+$my_config{'APXS'} = delete $my_config{'WITH_APXS'};
my $my_config_dump = join ,\n,
map { qq{'$_' = } .
($my_config{$_} =~ /^\d+$/ ? $my_config{$_} : qq{'$my_config{$_}'})
} sort keys %my_config;
local *FH;
open FH, 'lib/Apache/MyConfig.pm' ||
die Can't open lib/Apache/MyConfig.pm: $!;
print FH EOT;
[Patch] perl Makefile.PL PREFIX=/foo/bar breakage
When passing a PREFIX=/foo/bar to Makefile.PL, all the perl .pm will get installed
under /foo/bar/lib/site_perl/perl-version/perl-arch but mod_perl.so isn't aware of
that. So, mod_perl will refuse to start, failing to locate Apache.pm. My first
way around this was to PerlRequire a file before anything else and push
/foo/bar/lib/site_perl/perl-version/perl-arch
on the @INC path, but it's not very elegant.
This patches automatically makes sure the PREFIX path, if specified, is placed first
in the @INC
path.
--
+---+
| Philippe M. Chiasson [EMAIL PROTECTED]|
| SmartWorker http://www.smartworker.org|
| IM : gozerhbe ICQ : gozer/18279998 |
| 64.8% computer corrupt according to |
| http://www.freespeech.org/ljk/purity.html |
+---+
You're much more likely to be knocked down by a snowball
than by an equivalent number of snowflakes.
-- Larry Wall
perl -e '$$=\${gozer};{$_=unpack(P26,pack(L,$$));/^Just Another Perl
Hacker!\n$/print||$$++redo}'
Index: src/modules/perl/mod_perl.c
===
RCS file: /home/cvs/modperl-1/src/modules/perl/mod_perl.c,v
retrieving revision 1.136
diff -u -U10 -b -B -I'$Id' -I'$Revision' -r1.136 mod_perl.c
--- src/modules/perl/mod_perl.c 2001/04/17 22:01:18 1.136
+++ src/modules/perl/mod_perl.c 2001/05/25 17:23:49
@@ -758,20 +758,25 @@
value would cause perl to try to free() something from the original env.
This crashed free(). */
my_setenv(MODPERL_ENV_FIXUP, 0);
my_setenv(MODPERL_ENV_FIXUP, NULL);
{
dTHR;
TAINT_NOT; /* At this time all is safe */
}
+#ifdef MOD_PERL_PREFIX
+ av_unshift(GvAV(incgv),1);
+ av_store(GvAV(incgv), 0, newSVpv(MOD_PERL_PREFIX,0));
+#endif
+
#ifdef APACHE_PERL5LIB
perl_incpush(APACHE_PERL5LIB);
#else
av_push(GvAV(incgv), newSVpv(server_root_relative(p,),0));
av_push(GvAV(incgv), newSVpv(server_root_relative(p,lib/perl),0));
#endif
/* *CORE::GLOBAL::exit = \Apache::exit */
if(gv_stashpv(CORE::GLOBAL, FALSE)) {
GV *exitgp = gv_fetchpv(CORE::GLOBAL::exit, TRUE, SVt_PVCV);
Index: apaci/mod_perl.config.sh
===
RCS file: /home/cvs/modperl-1/apaci/mod_perl.config.sh,v
retrieving revision 1.23
diff -u -U10 -b -B -I'$Id' -I'$Revision' -r1.23 mod_perl.config.sh
--- apaci/mod_perl.config.sh2001/01/29 18:11:41 1.23
+++ apaci/mod_perl.config.sh2001/05/25 17:20:11
@@ -175,20 +175,25 @@
perl_static_srcs=$param_PERL_STATIC_SRCS
perl_static_objs=`echo $param_PERL_STATIC_SRCS | sed -e 's:\.c:.o:g'`
perl_static_objs_pic=`echo $param_PERL_STATIC_SRCS | sed -e 's:\.c:.lo:g'`
#
# determine defines
#
perl_defs=''
perl_defs=$perl_defs -DMOD_PERL_VERSION=\\\$param_MOD_PERL_VERSION\\\
perl_defs=$perl_defs
-DMOD_PERL_STRING_VERSION=\\\mod_perl/$param_MOD_PERL_VERSION\\\
+
+if [ .$param_MOD_PERL_PREFIX != . ]; then
+ perl_defs=$perl_defs -DMOD_PERL_PREFIX=\\\$param_MOD_PERL_PREFIX\\\
+fi
+
perl_defs=$perl_defs
OIFS=$IFS IFS=$DIFS
for hook in \
DISPATCH CHILD_INIT CHILD_EXIT POST_READ_REQUEST TRANS HEADER_PARSER \
ACCESS AUTHEN AUTHZ TYPE FIXUP HANDLER LOG INIT CLEANUP STACKED_HANDLERS \
METHOD_HANDLERS DIRECTIVE_HANDLERS SECTIONS RESTART SSI TRACE THREADS; do
eval val=\$param_PERL_${hook}
case $hook in
TRACE|THREADS )
if [ .$val = .yes ]; then
Index: Makefile.PL
===
RCS file: /home/cvs/modperl-1/Makefile.PL,v
retrieving revision 1.184
diff -u -U10 -b -B -I'$Id' -I'$Revision' -r1.184 Makefile.PL
--- Makefile.PL 2001/05/01 17:08:25 1.184
+++ Makefile.PL 2001/05/25 17:16:20
@@ -221,20 +221,21 @@
$ADD_MODULE = ;
$PERL_DIRECTIVE_HANDLERS = 0;
$PERL_TABLE_API = 0;
$PERL_LOG_API = 0;
$PERL_URI_API = 0;
$PERL_UTIL_API = 0;
$PERL_FILE_API = 0;
$PERL_CONNECTION_API = 1; #these two were split out late in the game
$PERL_SERVER_API = 1; #so they are on by default
$PERL_RUN_XS = 0;
+$MOD_PERL_PREFIX;
my %experimental = map { $_,1 } qw{
PERL_AUTOPRELOAD
PERL_DSO_UNLOAD
PERL_STARTUP_DONE_CHECK
PERL_RUN_XS
PERL_MARK_WHERE
DO_INTERNAL_REDIRECT
PERL_TIE_SCRIPTNAME
PERL_STASH_POST_DATA
@@ -329,20 +330,27 @@
$win32_args{$k} = ($k eq 'DEBUG' or $k eq 'EAPI') ? 1 : $v;
}
else {
push @mm_args, $_;
}
next;
}
unless (/^(PERL|APACHE)/ or is_mp_arg($k)) {
push @mm_args, $_;
}
+
+ if($k eq 'PREFIX')
+ {
+ use File::Spec;
+ $MOD_PERL_PREFIX =
+File::Spec-catfile($v,'lib','site_perl',$Config{'version'},$Config{'archname'});
+ }
+
$v = 1 unless defined $v;
if($experimental{$k}) {
$experimental{$k}++;
RE: Apache::Session / No-Cookie-Tracking
Seems like the site in question is using either a hidden form element or a session cookie. I'm guessing that with the session being only valid as long as the browser window is open a session cookie is being used. The reason you don't see this in the Cookie directory for you particular browser is that these cookies are stored in the memory - they are not to be save after the browser session is over. I hope that helps. Joe Breeden -- Sent from my Outlook 2000 Wired Deskheld (www.microsoft.com) -Original Message- From: Jonathan Hilgeman [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 11:29 AM To: '[EMAIL PROTECTED]' Subject: FW: Apache::Session / No-Cookie-Tracking Sure - I believe in magic, depending on your definition of it. I KNOW there's a 4th method, because I've seen it work. There is an e-commerce web site which uses an outside cart programmed in CGI (Perl?). The original web site passes no identifying marks such as the session ID through the URL or through the form's submit button to add an item to the cart. I know, because I designed and created the web site. However, when the visitors hit the submit button, they are taken to another program/website containing their shopping basket filled with their items. I have figured out that it relies somewhat on the IP address, but not completely, because I have tested it behind the firewall and the other computer behind the firewall with me does not share the same basket. Once I am at that screen (viewing the contents of my cart on the program), there are other links which contain a session ID of sorts carried via the URL. The thing that is driving my head crazy is how they identify the user in the first place to create the links with the session ID. I accidentally caught them during testing or something and got a variable on the URL line. (I substituted the domain name - it's not really cart.com) http://www.cart.com/cgi-bin/cart.cgi?cartidnum=208.144.33.190T990806951R5848 E cartidnum seems to be: $IP-Address + T + Unix-TimeStamp + R + Unknown number + E By the way, the session only seems to active until the browser completely shuts down. Any ideas? If I could identify my users on another site without using cookies at all, that would be fantastic! Jonathan -Original Message- From: Ilya Martynov [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 9:02 AM To: Jonathan Hilgeman Cc: '[EMAIL PROTECTED]' Subject: Re: Apache::Session / No-Cookie-Tracking JH I want to be able to track visitors without the use of cookies. JH I don't want to rely on IP address, because people behind proxies and JH firewalls seem to have the same IP address. JH I don't want to rely on a session ID variable being always present in the JH URL, in case the window gets closed or changed. JH Now, two questions: JH 1) Will Apache::Session provide an environment variable like JH HTTP_USER_AGENT that will contain an identifier that will always JH be consistent for that specific user, despite proxies and JH firewalls, and despite the changing/closing of windows? JH 2) If not, does anyone know of a good way to do this? Do you believe in magic? :) The only way to track visitors is either: 1) use cookies 2) use session ID variable in URI and/or hidden field with session ID in forms 3) use IPs (which is bad because it is completely broken approach) 4) use HTTP authorization (which is not always convenient because requires user registration) Apache::Session can only create persistent storage of session data. Each session data identified by some session ID. This ID should be taken from somewhere (see above). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
RE: Apache::Session / No-Cookie-Tracking
You may also want to store a hidden field in every form with a sesionid that is generated by you. Depending on how unique the number needs to be, we use either the number generated by mod_unique_id - potentially less reliable - (a part of the standard apache dist) or generate one with MD5 - generally more reliable. Joe -Original Message- From: Jonathan Hilgeman [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 11:51 AM To: 'Ilya Martynov' Cc: '[EMAIL PROTECTED]' Subject: RE: Apache::Session / No-Cookie-Tracking The feeling of magic only lasts until you know how it's done, and I have seen the light. What happens is that they use a per-session cookie, so it doesn't appear in my temp folder. But, if per-session cookies are disabled, then it relies on the IP address. I guess that is better than just one method, but I think I may use the same method, but base the no-cookie method on both IP address AND HTTP_USER_AGENT to try to make things more unique. Jonathan -Original Message- From: Ilya Martynov [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 9:35 AM To: Jonathan Hilgeman Subject: Re: Apache::Session / No-Cookie-Tracking JH Sure - I believe in magic, depending on your definition of it. I KNOW JH there's a 4th method, because I've seen it work. There is an e-commerce web JH site which uses an outside cart programmed in CGI (Perl?). The original web JH site passes no identifying marks such as the session ID through the URL or JH through the form's submit button to add an item to the cart. I know, because JH I designed and created the web site. JH [..skip..] Interesting. If you will say me url of your web site where you are using this outside cart probably I'll find how they do tracking. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
RE: Concepts of Unique Tracking
Dialup users will be given high-speed connections using network cards and modems will be burned. It'll be like book-burning sessions all over again. Jonathan -Original Message- From: Ilya Martynov [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 10:53 AM To: Jonathan Hilgeman Cc: '[EMAIL PROTECTED]' Subject: Re: Concepts of Unique Tracking JH Let's take over the world and recompile all browsers to have them send out JH the MAC address of thet network card. .. and if I'm dialup user :) JH Jonathan JH -Original Message- JH From: Wim Kerkhoff [mailto:[EMAIL PROTECTED]] JH Sent: Friday, May 25, 2001 10:42 AM JH To: Jonathan Hilgeman JH Cc: '[EMAIL PROTECTED]' JH Subject: Re: Concepts of Unique Tracking JH Jonathan Hilgeman wrote: What about client-specific information available in Javascript, like JH screen resolution, size, etc...? Can that be accessed by tinkering with Apache a bit, or is it something only available because of the browser, since Javascript is dependent on the browser? JH I briefly thought about suggesting something like that, or with JH combination with the other headers that get sent in the HTTP request for JH language, encoding, etc. However, think of the situations such as JH computer labs, internet cafes, etc, where all computers are identical in JH every aspect, with the exact same version of the browser, hard coded JH screen resolutions (e.g. 800x600), etc, that the user can not change. JH -- JH Regards, JH Wim Kerkhoff, Software Engineer JH Merilus, Inc. -|- http://www.merilus.com JH Email: [EMAIL PROTECTED] -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
RE: Concepts of Unique Tracking
How quickly we forget ... Don't we remember the huge outcry over Intel putting a unique ID in every CPU which would could be transmitted via web browser and destroy all of our privacy? The frustration we feel as programmers who are trying to identify anonymous visitors is exactly what privacy is all about. And I am thankful for it. Get used to it. People need to opt-in in order to be identified. The closest thing we can get to this is people leaving their cookies enabled on their browser. Stephen At 10:43 AM 5/25/2001 -0700, Jonathan Hilgeman wrote: Let's take over the world and recompile all browsers to have them send out the MAC address of thet network card. Jonathan
RE: Apache::Session / No-Cookie-Tracking
One easy way to find out if the original site uses cookies is by using lynx with the mime_header argument: lynx -mime_header http://e-commerce-site-in-question/foo/bar | less This will print out the HTTP headers before the content, like show below: HTTP/1.1 200 OK Date: Fri, 25 May 2001 18:04:32 GMT Server: Apache/1.3.12 (Unix) Expires: Thu, 24 May 2001 18:04:33 GMT Pragma: no-cache Set-Cookie: FOO=BAR; domain=e-commerce-site-in-question; path=/cgi-bin Connection: close Content-Type: text/html HTML HEAD ---snip--- If that Set-Cookie header is there, the script uses cookies. The -mime_header argument may vary by version of lynx (i think). Check the man page if the syntax above doesn't work. Alternatively, you can telnet to port 80 of the website and do a GET /path/to/script. Just make sure you have lots of scrollback if the page has lots of content. =P P.S. I'm pretty sure Explorer 5.x does NOT store session cookies on disk, but other browsers may. --Alex -Original Message- From: Joe Breeden Sent: Friday, May 25, 2001 12:55 PM To: '[EMAIL PROTECTED]' Subject: RE: Apache::Session / No-Cookie-Tracking Seems like the site in question is using either a hidden form element or a session cookie. I'm guessing that with the session being only valid as long as the browser window is open a session cookie is being used. The reason you don't see this in the Cookie directory for you particular browser is that these cookies are stored in the memory - they are not to be save after the browser session is over. I hope that helps. Joe Breeden -- Sent from my Outlook 2000 Wired Deskheld (www.microsoft.com) -Original Message- From: Jonathan Hilgeman [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 11:29 AM To: '[EMAIL PROTECTED]' Subject: FW: Apache::Session / No-Cookie-Tracking Sure - I believe in magic, depending on your definition of it. I KNOW there's a 4th method, because I've seen it work. There is an e-commerce web site which uses an outside cart programmed in CGI (Perl?). The original web site passes no identifying marks such as the session ID through the URL or through the form's submit button to add an item to the cart. I know, because I designed and created the web site. However, when the visitors hit the submit button, they are taken to another program/website containing their shopping basket filled with their items. I have figured out that it relies somewhat on the IP address, but not completely, because I have tested it behind the firewall and the other computer behind the firewall with me does not share the same basket. Once I am at that screen (viewing the contents of my cart on the program), there are other links which contain a session ID of sorts carried via the URL. The thing that is driving my head crazy is how they identify the user in the first place to create the links with the session ID. I accidentally caught them during testing or something and got a variable on the URL line. (I substituted the domain name - it's not really cart.com) http://www.cart.com/cgi-bin/cart.cgi?cartidnum=208.144.33.190T 990806951R5848 E cartidnum seems to be: $IP-Address + T + Unix-TimeStamp + R + Unknown number + E By the way, the session only seems to active until the browser completely shuts down. Any ideas? If I could identify my users on another site without using cookies at all, that would be fantastic! Jonathan -Original Message- From: Ilya Martynov [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 9:02 AM To: Jonathan Hilgeman Cc: '[EMAIL PROTECTED]' Subject: Re: Apache::Session / No-Cookie-Tracking JH I want to be able to track visitors without the use of cookies. JH I don't want to rely on IP address, because people behind proxies and JH firewalls seem to have the same IP address. JH I don't want to rely on a session ID variable being always present in the JH URL, in case the window gets closed or changed. JH Now, two questions: JH 1) Will Apache::Session provide an environment variable like JH HTTP_USER_AGENT that will contain an identifier that will always JH be consistent for that specific user, despite proxies and JH firewalls, and despite the changing/closing of windows? JH 2) If not, does anyone know of a good way to do this? Do you believe in magic? :) The only way to track visitors is either: 1) use cookies 2) use session ID variable in URI and/or hidden field with session ID in forms 3) use IPs (which is bad because it is completely broken approach) 4) use HTTP authorization (which is not always convenient because requires user registration) Apache::Session can only create persistent storage of session data. Each session data identified by some session ID. This ID should be taken from somewhere (see above). --
RE: What the user in user agent means
True, sometimes people can be stupid and tinker around with their setups without knowing what they are doing, and they end up preventing themselves from being able to shop online, etc... Then they call the owner of the store and complain that their system doesn't work, and then the owners call us and tell us that the program we made for them does not work, and we have to reverse the chain and explain everything once again. In my opinion, that is working against the web. Someone can be identified uniquely and tracked without losing their privacy - history and personal information doesn't necessarily have to be linked to the identifier, which seems to be the big fuss. That is a browser issue. The whole purpose of web pages is to provide information EASILY to users. Now, if the user's program refuses to identify itself or allow the correct information to come in, whether by accident or intentionally, then that becomes a problem. It's like someone standing outside an unlocked door to a house they want to get in to, and they're shouting at the people inside, Let me in! Let me in! Seems like most web users are fairly stupid, and we can't expect them to learn everything. That's why the browsers should allow the web page programmers to help the users without them having to learn things. You can use the old adage, Give a man a fish and you'll feed him for a day. Teach him to fish and you'll feed him for a lifetime. However, we just cannot teach everyone that visits unless they want to learn, and if they want to learn, they will most likely know before they even get to the site. Jonathan -Original Message- From: Jeffrey W. Baker [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 11:19 AM To: [EMAIL PROTECTED] Subject: What the user in user agent means Why are we talking about tracking again? The user agent acts on behalf of the user. It is their agent. It is not your agent. Your content or program is a guest of the user agent, not its master. Learn to work with the web not against it.
[OT] Re:What the user in user agent means
On Friday, May 25, 2001, Jonathan Hilgeman wrote the following about What the user in user agent means JH The whole purpose of web pages is to provide information EASILY to users. JH Now, if the user's program refuses to identify itself or allow the correct JH information to come in, whether by accident or intentionally, then that JH becomes a problem. It's like someone standing outside an unlocked door to a JH house they want to get in to, and they're shouting at the people inside, JH Let me in! Let me in! Seems like most web users are fairly stupid, and we JH can't expect them to learn everything. That's why the browsers should allow JH the web page programmers to help the users without them having to learn JH things. JH But who decides what is helping? Are you going to help me by remembering my purchasing habits, and then informing the government/other companies, etc. what I am purchasing. Remember E-Toys and its customer list? Your help comment is an example of .. the road to hell is paved with good intentions (yet another old adage ... grin). Technology issues aside, this is starting to veer way OT ... its starting to belong on an EFF forum, and not here in mod_perl. Regards, Mike Miller [EMAIL PROTECTED]
Mod Perl Tutorials??
Will there be other conferences later in the year that will offer these types of mod perl tutorials?? Thanks. http://conferences.oreillynet.com/cs/os2001/pub/10/mod_perl_tutorials.ht ml
Re: Getting the wrong URL
On Fri, 25 May 2001 23:28:44 +0800 (SGT), Stas Bekman said: We're not doing anything with Apache::Registry. Everything is with Perl handlers. It always seemed to me that the problems described at those locations were specific to Apache::Registry. So you're saying that if a Perl handler module falls over for some reason, that child will continue serving the last content it served, forever? This strikes me as a bad thing. It's quite possible if you happen to create closures in your dispatch handler for example. It's a bad thing :) I sort of had the impression that closures were a good way to leak memory, and so avoided them. Anyways, all of the possible reasons listed there are not, as far as we can tell, going on in our code. Everything is 100% OO, nothing is global or exported, and everything uses strict and warnings. Perhaps I'm misunderstanding when things actually pass out of scope in a mod_perl environment. Since almost all of the availble documentation seems to be about using Apache::Registry, rather than about writing handlers, it's not always clear whether things like this necessarily translate to both. I'd switch to a single server mode first thing first. Do you see the same behavior with httpd -X? Same behavior, yes. Once one handler get a server error, you'll get the last succssful content served by that child, repeatedly, forever. Note also that this not one handler with lots of different behaviors. It's about 20 handlers, based of some shared base modules, but performing rather different tasks. -- Rich Bowen - Author - Apache Server Unleashed http://www.apacheunleashed.com/
RE: Concepts of Unique Tracking
Although I agree about privacy issues, I will keep it short by stating that there is a difference between identifying you as unique user 1309850825 (assuming no personally identifiable information is also collected) versus identifying you as Stephen Adkins. You can use the first method to collect aggregate information about what percentage of your users are accessing what parts of your website the most/least, so you could customize your website appropriately. That does not require me to know who everyone is, personally speaking. --Alex -Original Message- From: Stephen Adkins [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 1:14 PM To: Jonathan Hilgeman; '[EMAIL PROTECTED]' Subject: RE: Concepts of Unique Tracking How quickly we forget ... Don't we remember the huge outcry over Intel putting a unique ID in every CPU which would could be transmitted via web browser and destroy all of our privacy? The frustration we feel as programmers who are trying to identify anonymous visitors is exactly what privacy is all about. And I am thankful for it. Get used to it. People need to opt-in in order to be identified. The closest thing we can get to this is people leaving their cookies enabled on their browser. Stephen At 10:43 AM 5/25/2001 -0700, Jonathan Hilgeman wrote: Let's take over the world and recompile all browsers to have them send out the MAC address of thet network card. Jonathan
Re: Handling the 'User pressed Stop button' case - not working
On Sat, 26 May 2001, Stas Bekman wrote: You right. It seems that mod_proxy won't abort on SIGPIPE. So how can I get it to without breaking everything else? Any ideas? I have a process that takes 2-3 minutes to run before the user gets any any output. I tell them to wait, but they get impatient. If they hit STOP I really want to know about it so I can free up CPU resources for when they hit RELOAD to try agin. Any helpful hints would be most appreciated. -- Matthew Darwin Community Volunteer [EMAIL PROTECTED] http://www.davin.ottawa.on.ca/~matthew/
Re: macintosh osX - mod_perl install problems
[EMAIL PROTECTED] (allan) wrote: im aware of the head/HEAD problem that comes with LWP on mac osX and have therefore copied a binary head that ken williams sent me into /usr/bin and moved the lwp head into /usr/local/bin. Looks like that problem still isn't fixed, as shown by the following error message: Usage: head [-options] url... -m method use method for the request (default is 'HEAD') You may have a different PATH than I do, or different capitalization on the binary files. The upshot is that when you run the 'head' command, it *must* run the /usr/bin/head program I sent you and not LWP's 'HEAD' script. Here's a transcript from my shell, what does yours say? [localhost:~] ken% which head /usr/bin/head [localhost:~] ken% which HEAD /usr/local/bin/HEAD ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: These are probably simple questions.
[EMAIL PROTECTED] (Bird Lei) wrote: If I upgraded Perl, do I need to recompile mod_perl? Yes. And if I have multiple Perls on a machine (eg 5.6.0 and 5.6.1. maybe in some non-standard directories), how can I tell mod_perl which one to use? Whichever one you compile mod_perl with: /usr/bin/perl5.6.0 Makefile.PL EVERYTHING=1 versus /usr/bin/perl5.6.1 Makefile.PL EVERYTHING=1 Where is the place to check for Perl's config such as @INC? Either through command-line 'perl -V', or through Apache::Status in a web browser. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
RE: Concepts of Unique Tracking
ASCEND SOAPBOX I agree with Alex (and it's not just because we work together). Companies have been doing the kind of data collecting Alex is talking about for years. As a matter of fact, some Cultural Anthropologists specialize in Corporate Anthropology (for a recent related news item see -http://www.cnn.com/2001/CAREER/dayonthejob/05/23/corp.anthropologist.idg/in dex.html ). Collecting anonymous information about users is something almost all websites do - I'm hesitant to say all, because I'm sure one website out there doesn't keep a usage log (i.e. /usr/local/apache/logs/access_log or /usr/local/apache/logs/error_log). It would be almost impossible to run a good website that changes based on user trends and preferences and not do some form of user tracking. Of course the real problem is when the website tries to link the collected data in someway to real people. Knowing that 15% of your users HTTP_REFERRER is www.porn.com is one thing, knowing that Persons X, Y, and Z came from www.porn.com and acting on that knowledge to send them information about the latest sale on leather underwear and selling their names to the porn_users mailing list is completely wrong. In my opinion, a good website has to track generalizations about user preferences so it can react to add to the user experience in positive ways. One way to do this to collect anonymous data about the things a user does on the site. This can be done and still protect a users privacy. DESCEND SOAPBOX Joe Breeden -- Sent from my Outlook 2000 Wired Deskheld (www.microsoft.com) -Original Message- From: Alex Porras Sent: Friday, May 25, 2001 2:38 PM To: '[EMAIL PROTECTED]' Subject: RE: Concepts of Unique Tracking Although I agree about privacy issues, I will keep it short by stating that there is a difference between identifying you as unique user 1309850825 (assuming no personally identifiable information is also collected) versus identifying you as Stephen Adkins. You can use the first method to collect aggregate information about what percentage of your users are accessing what parts of your website the most/least, so you could customize your website appropriately. That does not require me to know who everyone is, personally speaking. --Alex -Original Message- From: Stephen Adkins [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 1:14 PM To: Jonathan Hilgeman; '[EMAIL PROTECTED]' Subject: RE: Concepts of Unique Tracking How quickly we forget ... Don't we remember the huge outcry over Intel putting a unique ID in every CPU which would could be transmitted via web browser and destroy all of our privacy? The frustration we feel as programmers who are trying to identify anonymous visitors is exactly what privacy is all about. And I am thankful for it. Get used to it. People need to opt-in in order to be identified. The closest thing we can get to this is people leaving their cookies enabled on their browser. Stephen At 10:43 AM 5/25/2001 -0700, Jonathan Hilgeman wrote: Let's take over the world and recompile all browsers to have them send out the MAC address of thet network card. Jonathan
Re: Handling the 'User pressed Stop button' case - not working
Matthew Darwin wrote: On Sat, 26 May 2001, Stas Bekman wrote: You right. It seems that mod_proxy won't abort on SIGPIPE. So how can I get it to without breaking everything else? Any ideas? I have a process that takes 2-3 minutes to run before the user gets any any output. I tell them to wait, but they get impatient. If they hit STOP I really want to know about it so I can free up CPU resources for when they hit RELOAD to try agin. Any helpful hints would be most appreciated. Run the process in the background. Have the browser loop on a reporting URL w/request ID. That will allow you to show progress: * The initial request generates a processing job. Please see previous threads regarding the wisdom of forking mod_perl processes. You may want to consider writing a lightweight daemon to take processing requests from mod_perl via a unix domain socket. * Return a starting page to the client which will refresh to a progress reporting URL, which may be the same URL as the original request (be sure to include a UUID or some other identifier for the job). * Each time the progress URL is called, check on the status of the processing job. Return the data if available, or return another refresh. Also: * The progress URL can use the UUID to generate updated status info. If you are clever, you can even offer a status bar. * If you keep the results of your processing jobs indexed by, say, the MD5 of the request parameters that created them, you can skip redundant processing runs. -jh
Re: Mod Perl Tutorials??
At 03:06 PM 5/25/01 -0400, Agoston, Rich wrote: Will there be other conferences later in the year that will offer these types of mod perl tutorials?? Thanks. http://conferences.oreillynet.com/cs/os2001/pub/10/mod_perl_tutorials.ht ml My belief (but Stas may be able to confirm or deny this) is that ApacheCon In Dublin will probably be his mod_perl tutorial next stop after OReilly conference. ApacheCon/Dublin is in October sometime. Later, Gunther
