Re: conditional get
Kyle Oppenheim wrote:
I assume you are running this script under Apache::Registry (since your URLs
have .pl extensions). Apache::Registry compiles your code into a subroutine
and runs it using this code:
my $old_status = $r->status;
my $cv = \&{"$package\::handler"};
eval { &{$cv}($r, @_) } if $r->seqno;
... snip ...
return $r->status($old_status);
Notice that it throws away the result of the eval {}, so it doesn't really
matter what you return. However, you can use $r->status from your script to
set the status code. Apache::Registry will return the value you set via
$r->status from it's handler() method. (I'm not sure why it's trying to set
$old_status at the same time.
$r->status($old_status) resets $r->status to $old_status while
returning the current value (before the set) of $r->status. this is
required because you're not supposed to mess with $r->status at all -
it's merely a workaround that Apache::Registry uses and that real
handlers are not supposed to.
If you look at the XS code it's clear that
$r->status returns the previously set value. Anybody know the reason?)
basically, apache sets $r->status to 200 (HTTP_OK) before anybody is
allowed to do anything. if you return SERVER_ERROR from your handler,
Apache sets $r->status to 500. but, if (after that) you use an
ErrorDocument to handle the error, that $r->status isn't 200 is
Apache's way of telling that you are in an ErrorDocument cycle so that
it doesn't infinitely recurse into more ErrorDocuments.
so again, this is why handlers don't ever set $r->status for real.
Also, Apache will call send_error_response for all 204, 3xx, 4xx, and 5xx
status codes. So, you shouldn't call send_http_header in these cases.
Finally, you probably also want to set the Last-Modified header for HTTP/1.0
clients that don't understand ETag headers. You can use $r->update_mtime
and $r->set_last_modified.
So, try the following change to your code:
$R->content_type ($data {mimetype});
$R->set_content_length ($data {size});
$R->header_out ('ETag',$data {md5});
don't do that. use the $r->set_etag method instead, which is probably
a bit safer than trying to figure out Etag rules yourself. I'm pretty
sure that you shouldn't use the Etag header with non-static entities
anyway, but I could be wrong.
$R->update_mtime($data {mtime});
$R->set_last_modified;
if ((my $rc = $R->meets_conditions) != OK) {
$R->status($rc);
and, again, don't do that unless you're using Apache::Registry. all
the rest looks right.
there are a few recipes in the cookbook that may help as well, since
they also illustrate various conditional processing idioms:
http://www.modperlcookbook.org/code/ch06/Cookbook/SendSmart.pm
http://www.modperlcookbook.org/code/ch08/Cookbook-Clean-0.03/Clean.pm
for example.
HTH
--Geoff
Re: Thoughts on Mason?
Chapter 8's code walk-thru of apprentice.perl.org is quite good. Kudos to whoever came up with idea to dedicate a chapter to discussing a production application. I've only read chs 8 and 10, but it looks like this book is going to be perfect for turning my novice-intermediate Perl developers into Mason gurus. My sense is that the book is really going expand Apache/modperl usage. Happy hacking, John [EMAIL PROTECTED]
Re: Thoughts on Mason?
On Thu, 24 Oct 2002, Shannon Appelcline wrote: > I see there's a new book coming out from O'Reilly on "mason", which seems > to be perl integrated into web pages and claims to support mod_perl. > > Any thoughts on mason from this esteemed community? I use it a lot; it rocks. You can't get stuff done faster than you can with Mason, and it still allows you to design things properly if you are careful. http://dev.perl.org/, http://jobs.perl.org, http://search.cpan.org/ are using Mason. See http://www.masonhq.com/ - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: code evaluation in regexp failing intermittantly
Rodney Hampton wrote:
Perrin, Danny, et. al.
I looked over the comparison document as well as the perldocs on all
the templating systems I could find on CPAN before embarking on this
journey.
I'll add in how Apache::ASP can be used to solve this problem...
I really only need 3 tags: one to link the templates together, one to
bring in images, and one to call code that can by dynamically
inserted. Every item in my application's database (templates,
images, and other files) has user and group permissions that need to
Apache::ASP lets you define custom tags like:
instead of <% link_name template_faq %>
instead of <% img_src_name some_image %>
These tags get rendered by subroutines you define my::link_name and my::img_src.
You can use global.asa Script_OnStart to do all the database handle setup
work to make this easily accessible to your XMLSubs ( the name of this tagging feature ).
Of course, maybe more like what you have now, in Apache::ASP, its easy to
also do:
<% &link_name("template_faq"); %>
but I personally like the XMLSubs approach because it takes a more
content oriented approach to your pages, than embedding code.
The trick to making easy local subs for all your pages is to define
these subs in your global.asa, which is the package all of your pages
are compiled into.
>>> be checked on access. Thus, any templating system that did caching is
pretty much out of the running because as soon as I revoke a user's
privileges or change permissions on the item, I want access to change
Apache::ASP does do output caching of includes only when explicitly
asked for, see:
http://www.apache-asp.org/objects.html#%24Response-%3EIa3beea1e
This is only for performance optimization, so you do not have to worry
about caching otherwise.
need to track users so I had to be able to establish and maintain a
session so this was a definate requirement. Also, I needed to be
able to selectively protect certain areas of the application with
login screens (not necessarily the same one depending on where you
Like other systems session management has been built into Apache::ASP
from the get go ( one of the reasons I started work on Apache::ASP ).
In that system, its the $Session object.
navigate). This is the underlying architecture for a client I have
but I intend to make it modular enough to use for future projects.
I've done some benchmarking on what I've built already and am
satisfied with the results. I seem to be able to serve up 30
concurrent connections sending dynamic content all day long and have
it sever between 25-35 requests per second at around 300 - 375
Kbytes/sec. I've compiled mod_perl with DSO and it's never shown any
For other benchmarking of the various web app environments you could
use, check out http://chamas.com/bench/
Anyway, I'm not trying to say that what I'm doing is better or worse
than what has come before. I just happen to have different
requirements and I didn't think that the other systems out there were
going to be both lightweight and allow me to meet my need for access
control.
As others have asserted, I believe if you look at the other systems
hard enough, you will find many others that can fill your requirements.
Regards,
Josh
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc.http://www.chamas.com
NodeWorks Link Checkinghttp://www.nodeworks.com
Re: code evaluation in regexp failing intermittantly
Rodney Hampton wrote: I really only need 3 tags: one to link the templates together, one to bring in images, and one to call code that can by dynamically inserted. Like an eval, or a subroutine call? Either way, this is all covered by most of the other systems. Even Apache::SSI can do this. Every item in my application's database (templates, images, and other files) has user and group permissions that need to be checked on access. Thus, any templating system that did caching is pretty much out of the running because as soon as I revoke a user's privileges or change permissions on the item, I want access to change immediately. The only one that has built-in caching of results is Mason, and it won't do it unless you tell it to. All other references to caching mean caching the template parsing. That wouldn't be an issue for this. I'm guessing from your previous post that these things are accessed by calling a subroutine from the templates, and the subroutine does the access checking. That should be no problem. Also, when an advertiser makes a change to one of his/her templates, it needs to propogate immediately. All of them handle that. They check for changes, usually by stat-ing the template files. Additionally, I need to track users so I had to be able to establish and maintain a session so this was a definate requirement. Session tracking has nothing to do with templates. Systems like Embperl and Apache::ASP (and now Mason) integrate it, but that's because they are much more than just template systems. With a typical pipeline arhcitecture, you would handle the session in your code and then pass the data (including whatever session data you need) off to the template. Also, I needed to be able to selectively protect certain areas of the application with login screens (not necessarily the same one depending on where you navigate). Access control also has nothing to do with templates. You can use something like Apache::AuthCookie for this, or you can handle it directly in your perl code. I've done some benchmarking on what I've built already and am satisfied with the results. It's easy to write a fast templating system. What's hard is writing a fast templating system that has no bugs, and can adapt to future needs. It doesn't take long before you find you need more features: whitespace control, a more powerful if/else construct, a way to format dates, etc. That's why the modules on CPAN seem big. They have been extended to handle most of the real-world problems that people need to solve with templating systems. Anyway, I'm not trying to say that what I'm doing is better or worse than what has come before. I just happen to have different requirements and I didn't think that the other systems out there were going to be both lightweight and allow me to meet my need for access control. I'm pretty sure that there are modules on CPAN that do just what you need. If you already have a working system, then go with it. If you find yourself having to revisit the code because you need to add things or are finding bugs or performance problems, consider benefitting from someone else's hard work. - Perrin
RE: Making a module-It can't be this hard.
Hi there, On Sat, 26 Oct 2002, Per Einar Ellefsen wrote: > At 00:01 26.10.2002, Robert Covell wrote: > > > >The modules I have declared do contain a package name. > > > >Is it not possible or easy to just use/require/include a pl or pm file that > >contains a set of function for me to reuse. Also: have you tried running httpd -X? See the mod_perl Guide (you'll find a link on the mod_perl home page http://perl.apache.org) 73, Ged.
Re: code evaluation in regexp failing intermittantly
Gang, I'm forwarding this to the list. Sorry Danny for sending it to your personally. Rodney Hampton Danny Rathjens wrote: Looks like you accidentally replied to just me instead of the group. Don't ask me why we don't have a reply-to header on the list, ;) Rodney Hampton wrote: Perrin, Danny, et. al. I looked over the comparison document as well as the perldocs on all the templating systems I could find on CPAN before embarking on this journey. I really only need 3 tags: one to link the templates together, one to bring in images, and one to call code that can by dynamically inserted. Every item in my application's database (templates, images, and other files) has user and group permissions that need to be checked on access. Thus, any templating system that did caching is pretty much out of the running because as soon as I revoke a user's privileges or change permissions on the item, I want access to change immediately. Also, when an advertiser makes a change to one of his/her templates, it needs to propogate immediately. Additionally, I need to track users so I had to be able to establish and maintain a session so this was a definate requirement. Also, I needed to be able to selectively protect certain areas of the application with login screens (not necessarily the same one depending on where you navigate). This is the underlying architecture for a client I have but I intend to make it modular enough to use for future projects. I've done some benchmarking on what I've built already and am satisfied with the results. I seem to be able to serve up 30 concurrent connections sending dynamic content all day long and have it sever between 25-35 requests per second at around 300 - 375 Kbytes/sec. I've compiled mod_perl with DSO and it's never shown any memory leaks for me (YMMV). That was done on a 851Mhz Dell Latitude laptop with 128MB RAM and I ran apache benchmark from this box as well (which skews my results but shows it can handle the load). The production server need only handle up to 50,000 users per day and it will be on much better hardware so I think I'm in fine shape so far. I'd like to think that I'm heading in the right direction. Believe me, I prefer to pull down modules from CPAN when possible. For example, I would eventually like to chain my PerlHandlers and zip up the content before delivery. There are modules to do that already so I won't be rewritting Apache::Filter from scratch for instance. I'd also like to pretty up the html before outputting it to the client browser - I'm pretty sure there's a module in there for that as well. Anyway, I'm not trying to say that what I'm doing is better or worse than what has come before. I just happen to have different requirements and I didn't think that the other systems out there were going to be both lightweight and allow me to meet my need for access control. Rodney Hampton Danny Rathjens wrote: Very useful document comparing templating systems: http://perl.apache.org/docs/tutorials/tmpl/comparison/comparison.html Perrin Harkins wrote: Rodney Hampton wrote: Let me preface it by stating that I'm building a very simple templating application. [...] Not satisfied, I wanted to make it possible to do something like: <% code_ref Util::Test_Util::test_expand %> and have it swap in the text output from the sub into the template. That way, unlike other templating applications, I could get away from writing my own mini language and use the full power of perl in a sub called by a simple tag in the template. Do you realize that almost every templating system on CPAN already does this? If you are doing this because you think you've hit on a new feature, stop now and download one of those. If you're doing it because hacking perl is fun and you're in no rush, then go ahead and have a good time. - Perrin
