RE: Apache::Cookie - weird values returned...
Eric Sammer wrote:
What is weird is that the Apache::Cookie object DOES exist, it's just
the value
that's all wacked out or just plain missing.
I've had problems with scripts and mod_perl code before where I
inadvertently create
keys in a hash when I'm testing to see if they exist. I now always use
something
Like:
if((exists($cookie-{user_id})) (defined($cookie-{user_id})))
Just doing if(defined .. Checks to see if the value of the key is
defined. If the
key did not exist previously it may be created by this process. The key
can exist but
hold an undefined value.
The problem is that the logout handler (which expires the user_id
cookie) kills the
cookie and redirects to / ok, but when the GroupAccess handler checks
if the cookie
exists (during the / request), $cookies-{user_id}* is defined, but
the value seems to
be an empty string ala .
Is this an internal redirect, or a redirect sent from the browser ? If
it's internal then
the cookie will still exist unless you deleted the key yourself, and if
you run the request
As a sub-request it can pick up the submitted cookie again even if you
have deleted the key
on your parent request object.
If it's coming back from the browser are you sure that the browser isn't
sending you an empty
Cookie? Maybe some users have broken browsers ?
You might also want to check hoe the cookie gets expired. What is the
expiry date that is set
on the Set-cookie: header that goes back to the client, and what is the
date on that machine?
Could you make do with per-session cookies (which have no expory date,
but are only valid for
the duration of that browser session) ?
Although it's helpful to get to the bottom of any issue, you might be
more at peace if you
just checked to see if the value of the cookie was valid. After all,
who's to say that the
cookie they're sending you is actually the same as the one you sent them
in the first place ;)
(Just for the record I don't actually use Apache::Cookie myself I look
in and set the headers)
Rob Lambden
Re: Apache::Cookie - weird values returned...
Rob Lambden wrote: I've had problems with scripts and mod_perl code before where I inadvertently create keys in a hash when I'm testing to see if they exist. I now always use something Like: i always use either defined or exists as appropriate to avoid these errors. i've gotten bitten in the bottom by the same things many times in the past... i learned my lesson. ;) If the key did not exist previously it may be created by this process. The key can exist but hold an undefined value. again, in this case, the key is an Apache::Cookie object which couldn't accidentally be created as a simple type like a string key can. Is this an internal redirect, or a redirect sent from the browser ? the logout handler expires the cookie, sets the Location header, and returns REDIRECT. in other words, it's not internal nor a subrequest (unless a returned REDIRECT with a Location header is still considered a subrequest - that would be a surprise to me). If it's internal then the cookie will still exist unless you deleted the key yourself, and if you run the request As a sub-request it can pick up the submitted cookie again even if you have deleted the key on your parent request object. yea... unfortunately, that's not the case here... the browser regains control enough to handle the Set-Cookie (again, unless my perl/mod_perl/cgi books are all out of date)... ;) If it's coming back from the browser are you sure that the browser isn't sending you an empty Cookie? the cookie is a real cookie (in the headers) with the absence of the value. specifically, the return value of the Apache::Cookie-value() method. Maybe some users have broken browsers ? with the current state of things, i'm sure that's part of it. :) that said, there's always a limited set of options on that front. most of my (personal) testing is with mozilla on linux built from source (gentoo portage, actually) but similar behavior is seen on my mac os x boxes. You might also want to check hoe the cookie gets expired. What is the expiry date that is set on the Set-cookie: header that goes back to the client, and what is the date on that machine? the expire *i'm* specifying is just a relative '-1D' to cause the browser to drop it. if there's a better way, i'm certainly open to suggestions. Could you make do with per-session cookies (which have no expory date, but are only valid for the duration of that browser session) ? actually, all of these cookies are per-session which is why this isn't a hey, the building is on fire! sort of problem. the logout is one of those superfulous things that might be needed should the non-tech staff force us to add the dreaded save my username/password feature to the site. either way, i'd rather try and get the problem out of the way prior to such escalation. Although it's helpful to get to the bottom of any issue, you might be more at peace if you just checked to see if the value of the cookie was valid. yea... i suppose that's an option (and it *was* like that). i just get scared when something isn't working exactly as i understand it to be. it's that age old developer mantra of unpredictable working code is worse than predictable broken code. After all, who's to say that the cookie they're sending you is actually the same as the one you sent them in the first place ;) damn browsers... damn cookies. i'm still waiting (and will be for a long time to come) for two things: working stateful web development and flying cars... something tells me the latter is a more attainable goal. ;) (Just for the record I don't actually use Apache::Cookie myself I look in and set the headers) i used to do that all the time too. i've always felt that abstraction prevents errors in the long run (or at least makes them easier to find). being wrong sucks. thanks for the response... i'll give some of these ideas a shot (again, where applicable). -- Eric Sammer [EMAIL PROTECTED] http://www.linuxstep.org
Re: mod_perl Installation and Configuration (fwd)
Hi there, On Mon, 10 Feb 2003, Devi .M wrote: I want to install mod_perl with apache and configure for it in Linux m/c. I have tried this and started the server also. When typed ./httpd -l in apache/bin it showed the following output http_core.c [snip] mod_perl.c Well congratulations, you have a mod_perl server! But I am not sure whether I have installed and configured properly. Can anyone help me and also give a sample file It's not as easy as just giving you a sample file. You really have to read the documentation, including the mod_perl Guide which is at http://perl.apache.org. If you're using a version 1.x of Apache and mod_perl make sure to read the version 1 documentation! Please also read the documents in the mod_perl source tree which tell you what information to post when asking for help. Things like 'perl -V' are often very useful. You might also like to check out Writing Apache Modules with Perl and C, ISBN 1-56592-567-X which you may find hard going at first and the mod_perl Developer's Cookbook, ISBN 0-672-32240-4 which contains some 'recipes'. 73, Ged.
Re: Apache::Cookie - weird values returned...
Eric Sammer wrote: the expire *i'm* specifying is just a relative '-1D' to cause the browser to drop it. if there's a better way, i'm certainly open to suggestions. The HTTP headers do not support relative dates as far as I know. Thus when you specify a relative date the code must claculate the expiry date for you and send it back to the browser. If a user has their date and time set such that the cookie is still valid they will continue to return it. You might want to consider invalidating the cookie by setting the content to an empty value as well as setting the expiry date. This would then mean that even if they still think it's valid they have no value, only an empty string (which, AFAIK, most browsers will treat as an invalid cookie). You might be more comfortable making the expiry more than a day old. I logged onto a machine the other day and started getting browser messages that my server's security certificate had expired or was not yet valid. It turned out that the RTC on the machine was set to 1980. Maybe the user just wanted to relive the 80's ;) Rob Lambden
Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
The logic here is simpler: 1. store the new status code (just in case the script has changed it) 2. reset the status code to the one before the script execution 3. if the script has attempted to change the status by itself and the execution status is Apache::OK return that new status. Otherwise return the execution status (which will be either Apache::OK or Apache::SERVER_ERROR) this is different that how Apache::Registry in 1.0 handles it, specifically under circumstances like redirects, where people typically do $r-headers_out(Location = '/foo'); $r-status(REDIRECT); return REDIRECT; what you're saying now is that the status is only propagated if you return OK. (at least that's what I _think_ you're saying - I'm still trying to get back after a week off :) the logic should probably be something like respect the execution status if it is OK or it matches the new status, making $r-status(REDIRECT); return OK; and $r-status(REDIRECT); return REDIRECT; both valid ways to effectively redirect the request from Registry. the $r-status() bit was always a hack - nobody is supposed to fiddle with $r-status, which is why mod_perl saves and restores it. we could do with a better way that saved us from all this logic for people who want to use Registry with the mod_perl API. perhaps a version of the Cooker that simply respected (and expected) the script to return a meaningful status code. thus, the script would return SERVER_ERROR if $@ is true, and the return status of the subroutine otherwise. of course, we can't do this in CGI-portable mode, but for folks that want to use Registry as a dispatch mechanism, this is really the preferred way. --Geoff
What is lastest stable version of mod_perl? newbie question.
What's the latest stable version of mod_perl? I believe the latest stable version of Apache is 1.3.19, which is what I am running. I am at mod_perl version 1.25. As I understand it, I need to recompile mod_perl with Apache 1.3.19 and perl 5.8 on sun box in order to get perl 5.8 (hitting an Oracle 9.0.1 database) working with the mod_perl scripts. Charlie 2/10/03 -- This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed. ==
Re: What is lastest stable version of mod_perl? newbie question.
On Mon, 10 Feb 2003, Charlie Smith wrote:
What's the latest stable version of mod_perl?
Always available at http://perl.apache.org/download
I believe the latest stable version of Apache is 1.3.19, which is what I am
running.
No, the latest stable Apache version is 2.0.44. However, you should
probably get the stable 1.x version, 1.3.27, since mod_perl 2.x is not
really stable yet. See http://httpd.apache.org
I am at mod_perl version 1.25.
As I understand it, I need to recompile mod_perl with Apache 1.3.19 and perl
5.8 on sun box in order to get perl 5.8 (hitting an Oracle 9.0.1 database)
working with the mod_perl scripts.
PLEASE spend some time at http://perl.apache.org perusing the VERY
comprehensive and clear documentation. I am not aware that you _need_ perl
5.8 to compile the latest apache and mod_perl, but you might as well get
it now since you are upgrading those packages too. perl 5.6.1 eould also
be fine; perl 5.6.0 has problems.
HTH,
- nick
Nick Tonkin {|8^)
[ANNOUNCE] mod_perl Developer's Cookbook available in Polish
for our native Polish speakers (as well as the archives), the Polish translation of the mod_perl Developer's Cookbook appears to be available and shipping. http://helion.pl/ksiazki/modpkp.htm I haven't seen it yet (nor do I read Polish) but the above site seems to include a tarball of the code with the comments translated as well. ftp://ftp.helion.pl/przyklady/modpkp.zip and, as a reminder, if you want the code in English, it is always available from our website http://www.modperlcookbook.org/code.html nice work Przemyslaw! --Geoff
Fw: [Perl] how to static link mod_perl 2 into apache 2.0
Forwarding this from another list, because it's more appropriate here :-) - Original Message - From: Ron Gidron Sent: Monday, February 10, 2003 3:48 PM Subject: [Perl] how to static link mod_perl 2 into apache 2.0 I am trying to install a Mason based system. This package requires mod_perl statically linked and not as a DSO. for this new installation I decided to test Apache 2.0 and mod_perl 2.0. I downloaded the source for both packages and I am able to configure and make / make test /make install for both without problems however when I issue the command "apachectl -l" I don't see any reference to mod_perl. I have tried playing with the ./configure options for apache (--enable-perl etc) but nothing seams to get me to where I need to go, this is getting quite frustrating... does anyone have any tips? have any of you installed this configuration before, do you happen to remember the order of steps you took? Regards, Ron Gidron.
Re: mod_perl Installation and Configuration (fwd)
But I am not sure whether I have installed and configured properly. Can anyone help me and also give a sample file What Ged suggested is essential, but here is a direct link to get you going: http://perl.apache.org/docs/1.0/guide/getwet.html plus http://perl.apache.org/docs/1.0/guide/install.html#How_can_I_tell_whether_mod_perl_is_running_ __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: What is lastest stable version of mod_perl? newbie question.
Nick Tonkin wrote: [...] I am not aware that you _need_ perl 5.8 to compile the latest apache and mod_perl... You need 5.8 only to work with threaded mpm (Apache 2.0) and mod_perl 1.99_08. http://perl.apache.org/docs/2.0/user/install/install.html#Prerequisites __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Fw: [Perl] how to static link mod_perl 2 into apache 2.0
Issac Goldstand wrote: Forwarding this from another list, because it's more appropriate here :-) - Original Message - *From:* Ron Gidron mailto:[EMAIL PROTECTED] *Sent:* Monday, February 10, 2003 3:48 PM *Subject:* [Perl] how to static link mod_perl 2 into apache 2.0 I am trying to install a Mason based system. This package requires mod_perl statically linked and not as a DSO. for this new installation I decided to test Apache 2.0 and mod_perl 2.0. I downloaded the source for both packages and I am able to configure and make / make test /make install for both without problems however when I issue the command apachectl -l I don't see any reference to mod_perl. I have tried playing with the ./configure options for apache (--enable-perl etc) but nothing seams to get me to where I need to go, this is getting quite frustrating... does anyone have any tips? have any of you installed this configuration before, do you happen to remember the order of steps you took? At this point only DSO is supported by 2.0. What's wrong with using DSO? The package requires mod_perl to be statically linked, but it talks about mod_perl-1.0. I'd first check with Mason folks whether 2.0 is supported at all. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
Geoffrey Young wrote: The logic here is simpler: 1. store the new status code (just in case the script has changed it) 2. reset the status code to the one before the script execution 3. if the script has attempted to change the status by itself and the execution status is Apache::OK return that new status. Otherwise return the execution status (which will be either Apache::OK or Apache::SERVER_ERROR) this is different that how Apache::Registry in 1.0 handles it, specifically under circumstances like redirects, where people typically do $r-headers_out(Location = '/foo'); $r-status(REDIRECT); return REDIRECT; what you're saying now is that the status is only propagated if you return OK. (at least that's what I _think_ you're saying - I'm still trying to get back after a week off :) the logic should probably be something like respect the execution status if it is OK or it matches the new status, making $r-status(REDIRECT); return OK; and $r-status(REDIRECT); return REDIRECT; both valid ways to effectively redirect the request from Registry. the $r-status() bit was always a hack - nobody is supposed to fiddle with $r-status, which is why mod_perl saves and restores it. we could do with a better way that saved us from all this logic for people who want to use Registry with the mod_perl API. perhaps a version of the Cooker that simply respected (and expected) the script to return a meaningful status code. thus, the script would return SERVER_ERROR if $@ is true, and the return status of the subroutine otherwise. of course, we can't do this in CGI-portable mode, but for folks that want to use Registry as a dispatch mechanism, this is really the preferred way. OK, so we are not done with it. The first thing I'd like to see is to have Apache::Registry and Apache::PerlRun agree on how they handle return codes, because they aren't the same. Once this happens, the Cooker will do the same. As you have mentioned we have a problem with relying on return status. Because if the script doesn't use the mod_perl API, it normally may return absolutely anything, which may mess things up. So the safest approach, is to run the script, ignore its return value (not status!) and return OK or SERVER_ERROR based on whether the execution was error-free or not. Plus add the hack of returning of the new status if it was changed by the script. That's the approach that is taken by Apache::Registry and it seems that most people are happy with it. PerlRun does return the execution status, but when I first made the Cooker use this approach we immediately received a bug report, where the script wasn't doing the right thing. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
Stas Bekman wrote: Geoffrey Young wrote: The logic here is simpler: 1. store the new status code (just in case the script has changed it) 2. reset the status code to the one before the script execution 3. if the script has attempted to change the status by itself and the execution status is Apache::OK return that new status. Otherwise return the execution status (which will be either Apache::OK or Apache::SERVER_ERROR) this is different that how Apache::Registry in 1.0 handles it, specifically under circumstances like redirects, where people typically do $r-headers_out(Location = '/foo'); $r-status(REDIRECT); return REDIRECT; what you're saying now is that the status is only propagated if you return OK. (at least that's what I _think_ you're saying - I'm still trying to get back after a week off :) the logic should probably be something like respect the execution status if it is OK or it matches the new status, making $r-status(REDIRECT); return OK; and $r-status(REDIRECT); return REDIRECT; both valid ways to effectively redirect the request from Registry. the $r-status() bit was always a hack - nobody is supposed to fiddle with $r-status, which is why mod_perl saves and restores it. we could do with a better way that saved us from all this logic for people who want to use Registry with the mod_perl API. perhaps a version of the Cooker that simply respected (and expected) the script to return a meaningful status code. thus, the script would return SERVER_ERROR if $@ is true, and the return status of the subroutine otherwise. of course, we can't do this in CGI-portable mode, but for folks that want to use Registry as a dispatch mechanism, this is really the preferred way. OK, so we are not done with it. The first thing I'd like to see is to have Apache::Registry and Apache::PerlRun agree on how they handle return codes, because they aren't the same. Once this happens, the Cooker will do the same. As you have mentioned we have a problem with relying on return status. Because if the script doesn't use the mod_perl API, it normally may return absolutely anything, which may mess things up. So the safest approach, is to run the script, ignore its return value (not status!) and return OK or SERVER_ERROR based on whether the execution was error-free or not. Plus add the hack of returning of the new status if it was changed by the script. That's the approach that is taken by Apache::Registry and it seems that most people are happy with it. PerlRun does return the execution status, but when I first made the Cooker use this approach we immediately received a bug report, where the script wasn't doing the right thing. The only thing that messed me up was when running a script with mod_cgi, you can return your own status codes and apache will happily go along with it. However, when you run the same script under mod_perl's Apache::Registry, you suddenly get Apache::Registry second guessing the script and adding to the script, something that for (especially) USE_LOCAL_COPY and PARTIAL_CONTENT responses is just wrong. I've just ended up writing my own version of Apache::Registry that always returns OK, which works for my purposes and therefore I'm content. The only thing that puzzles me about this thread is that it seems to be leaning towards the position that says; If the developer just does straight out weird stuff and messes with $r-status in a cgi-script and expects it to work with Apache::Registry (which as far as I understand is a cgi emulation layer), we will accommodate them. However, if the s/he just expects Apache::Registry to behave like it mod_cgi (except faster, more brilliant, etc :)) then they will be disappointed. I am probably just fixated over my current work and can't see the proverbial forest. Can somebody explain this for me?
Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
David Dick wrote: [...] The only thing that messed me up was when running a script with mod_cgi, you can return your own status codes and apache will happily go along with it. However, when you run the same script under mod_perl's Apache::Registry, you suddenly get Apache::Registry second guessing the script and adding to the script, something that for (especially) USE_LOCAL_COPY and PARTIAL_CONTENT responses is just wrong. I've just ended up writing my own version of Apache::Registry that always returns OK, which works for my purposes and therefore I'm content. The only thing that puzzles me about this thread is that it seems to be leaning towards the position that says; If the developer just does straight out weird stuff and messes with $r-status in a cgi-script and expects it to work with Apache::Registry (which as far as I understand is a cgi emulation layer), we will accommodate them. However, if the s/he just expects Apache::Registry to behave like it mod_cgi (except faster, more brilliant, etc :)) then they will be disappointed. I am probably just fixated over my current work and can't see the proverbial forest. Can somebody explain this for me? Personally I don't see how is it possible to accomodate everybody in the same handler. Because the requirements are conficting and second guessing is working in 99% but breaks for 1%, causing torn out hairs. Perhaps having two different sub-classes which do things differently is the right way to go. The default should follow the course of the least surprise and accomplish what it was designed for in first place: emulate mod_cgi, while giving the speed benefits. The other sub-class should pitch towards developers that use registry, for scripts which are expected to behave differently from mod_cgi. Looks like that's what we have under mod_perl 1.0. Apache::Registry and Apache::PerlRun/RegistryNG behave differently and one should choose between the two according to their needs. Even though the overall implementation is different for a different reason (make a sub-classable registry). __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [ANNOUNCE] mod_perl Developer's Cookbook available in Polish
Geoffrey Young [EMAIL PROTECTED] writes: for our native Polish speakers (as well as the archives), the Polish translation of the mod_perl Developer's Cookbook appears to be available and shipping. http://helion.pl/ksiazki/modpkp.htm Thanks! That's the great news for me (especially considering that 69z =~ 18$ and I can buy it nearby). -- ( Marcin Kasperski | Osoba jest omegalizacj ewolucji uniwersalnej na ) ( http://www.mk.w.pl | okrelonym odcinku etapowym (Teilhard de Chardin) ) () ( Wygeneruj dokumentacj: http://www.mk.w.pl/narzedzia/narzedzia_gendoc )
Install on s390
Hi Group, Has anyone out there installed mod_perl on Linux for s390 (SuSE, RH or Debian)? I'd be very interested in any success stories or gotchas before I start on that journey. Steve
[ANNOUNCE] Apache::ASP v2.51 released
Hey,
Apache::ASP v2.51 is released to CPAN. You can get it from your local
CPAN archive or here:
http://www.cpan.org/modules/by-module/Apache/
Below are the changes. This is a big release, and though it is
well tested, please upgrade carefully.
For more info on Apache::ASP, please see http://www.apache-asp.org
About Apache::ASP...
Apache::ASP provides an Active Server Pages port to the
Apache Web Server with Perl scripting only, and enables developing of
dynamic web applications with session management and embedded perl code.
There are also many powerful extensions, including XML taglibs, XSLT rendering,
and new events not originally part of the ASP API!
Regards,
Josh
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc.http://www.chamas.com
NodeWorks Link Checkinghttp://www.nodeworks.com
CHANGES ==
$VERSION = 2.51; $DATE=02/10/2003
+ added t/session_query_parse.t test to cover use of SessionQueryParse
and $Server-URL APIs
- Fixed duplicate bug associated with using $Server-URL
and SessionQueryParse together
+ Patch to allow $Server-URL() to be called multiple times on the same URL
as in $Server-URL($Server-URL($url, \%params), \%more_params)
(d) Added new testimonials sites created a separate testimonials page.
- SessionQueryParse will now add to amp; to the query strings
embedded in the HTML, instead of for proper HTML generation.
Thanks to Peter Galbavy for pointing out and Thanos Chatziathanassiou
for suggesting the fix.
- $Response-{ContentType} set to text/html for developer error reporting,
in case this was set to something else before the error occured.
Thanks to Philip Mak for reporting.
- Couple of minor bug fixes under PerlWarn use, thanks Peter Galbavy
for reporting.
+ Added automatic load of use Apache2 for compat with mod_perl2
request objects when Apache::ASP is loaded via PerlModule Apache::ASP
Thanks to Richard Curtis for reporting bug subsequent testing.
- When GlobalPackage config changes, but global.asa has not, global.asa
will be recompiled anyway to update the GlobalPackage correctly.
Changing GlobalPackage before would cause errors if global.asa was
already compiled.
++ For ANY PerlSetVar type config, OFF/Off/off will be assumed
to have value of 0 for that setting. Before, only a couple settings
had this semantics, but they all do now for consistency.
- Fix for InodeNames config on OpenBSD, or any OS that might have
a device # of 0 for the file being stat()'d, thanks to Peter Galbavy
for bug report.
++ Total XSLT speedups, 5-10% on large XSLT, 10-15% on small XSLT
+ bypass meta data check like expires for XSLT Cache() API use
because XSLT tranformations don't expire, saves hit to cache dbm
for meta data
+ use of direct Apache::ASP::State methods like FETCH/STORE
in Cache() layer so we don't have to go through slower tied interface.
This will speed up XSLT and include output caching mostly.
+ minor optimizations for speed memory usage
