Re: [RELEASE CANDIDATE] mod_perl-2.0.4 RC1
Ahem, On that subject, libapreq1 is already a year and a half into it's latest release cycle. We're still waiting for a PMC vote to finish the release... Someone remind me to do a lightning talk about this next time I'm at AC :) Foo JH wrote: Fantastic! Can I assume that libapreq will be compatible with this version? In all likelihood the only way is to try it yourself... Philippe M. Chiasson wrote: The mod_perl 2.0.4 release candidate 1 Works with Perl 5.10 is ready. It can be downloaded here: http://www.apache.org/~gozer/mp2/mod_perl-2.0.4-rc1.tar.gz MD5: 1f0a941e8b5f26b6102126ae67ddbb43 SHA1: 8b2ceede3c783b9b2cc9e0fe63a095b0e4a1f000 Please give it a spin in your favorite configuration and report any problems. Especially needed against Perl-5.10 on Windows. The summary of what has changed since 2.0.3 are (from Changes): Fix $r-location corruption under certain conditions [Gozer] Fix a crash when spawning Perl threads under Perl 5.10 [Gozer] Fix erratic behaviour when filters were used with Perl 5.10 [Gozer] Fix problems with redefinitions of perl_free as free and perl_malloc as malloc on Win32, as described at http://marc.info/?l=apache-modperlm=119896407510526w=2 [Tom Donovan] Fix a crash when running a sub-request from within a filter where mod_perl was not the content handler. [Gozer] Refactor tests to use keepalives instead of same_interp [Gozer, Phred] Apache2::Reload has been moved to an externally maintained CPAN distribution [Fred Moyer [EMAIL PROTECTED]] PerlCleanupHandler are now registered with a subpool of $r-pool, instead of $r-pool itself, ensuring they run _before_ any other $r-pool cleanups [Torsten Foertsch] Fix a bug that would prevent pnotes from being cleaned up properly at the end of the request [Torsten Foertsch] On Win32, embed the manifest file, if present, in mod_perl.so, so as to work with VC 8 [Steve Hay, Randy Kobes] Expose apr_thread_rwlock_t with the APR::ThreadRWLock module [Torsten Foertsch] Don't waste an extra interpreter anymore under threaded MPMs when using a modperl handler [Torsten Foertsch] Fix a bug that could cause a crash when using $r-push_handlers() multiple times for a phase that has no configured handlers [Torsten Foertsch] Catch up with some httpd API changes 2.2.4: The full server version information is now included in the error log at startup as well as server status reports, irrespective of the setting of the ServerTokens directive. ap_get_server_version() is now deprecated, and is replaced by ap_get_server_banner() and ap_get_server_description(). [Jeff Trawick] 2.3.0: ap_get_server_version() has been removed. Third-party modules must now use ap_get_server_banner() or ap_get_server_description(). [Gozer] fixed Apache2::compat Apache2::ServerUtil::server_root() resolution issues [Joshua Hoblitt] *) SECURITY: CVE-2007-1349 (cve.mitre.org) fix unescaped variable interprolation in regular expression [Randal L. Schwartz [EMAIL PROTECTED], Fred Moyer [EMAIL PROTECTED]] Make $r-the_request() writeable [Fred Moyer [EMAIL PROTECTED]] fix ModPerl::RegistryCooker::read_script to handle all possible errors, previously there was a case where Apache2::Const::OK was returned on an error. [Eivind Eklund [EMAIL PROTECTED]] a minor compilation warning resolved in modperl_handler_new_from_sv [Stas] a minor compilation warning resolved in modperl_gtop_size_string [Stas] Prevent direct use of _deprecated_ Apache2::ReadConfig in Perl sections with httpd Alias directives from incorrectly generating 'The Alias directive in x at line y will probably never match' messages. [Philip M. Gollucci [EMAIL PROTECTED]] Prevent Apache2::PerSections::symdump() from returning invalid httpd.conf snippets like 'Alias undef' [Philip M. Gollucci [EMAIL PROTECTED]] Require B-Size 0.9 for Apache2::Status which fixes Can't call method script_name on an undefined value [Philip M. Gollucci [EMAIL PROTECTED]] -march=pentium4 or anything with an = in it in CCFLAGS or @ARGV that gets passed to xs/APR/APR/Makefile.PL broke the @ARGV parsing. I.E. FreeBSD port builds when users had CPUTYPE set in /etc/make.conf. [Philip M. Gollucci [EMAIL PROTECTED]] Fixes to get bleed-ithread (5.9.5+) to comile again. [Philip M. Gollucci [EMAIL PROTECTED]]
Re: [RELEASE CANDIDATE] mod_perl-2.0.4 RC1
Issac Goldstand wrote: Ahem, On that subject, libapreq1 is already a year and a half into it's latest release cycle. We're still waiting for a PMC vote to finish the release... Someone remind me to do a lightning talk about this next time I'm at AC :) Time for a FFT presentation - 15 minutes on cutting edge POST handling using apreq? Just give [EMAIL PROTECTED] a title, abstract, presenter and short bio. Bill
Re: [RELEASE CANDIDATE] mod_perl-2.0.4 RC1
William A. Rowe, Jr. wrote: Issac Goldstand wrote: Ahem, On that subject, libapreq1 is already a year and a half into it's latest release cycle. We're still waiting for a PMC vote to finish the release... Someone remind me to do a lightning talk about this next time I'm at AC :) Time for a FFT presentation - 15 minutes on cutting edge POST handling using apreq? Just give [EMAIL PROTECTED] a title, abstract, presenter and short bio. Not I - I won't be there. I'm trying to get my wife (and boss, but he's less of an issue if I can talk there) to come around to the idea of AC US 2008. I can do it then.
Re: Question: how to change the request in input filter and pass it to proxy
On 03/04/2008, Olexandr Prokhorenko [EMAIL PROTECTED] wrote: Hi everyone, I am working on the input filter which is going to catch on input requests, find the bucket with Host: , modify it and pass it through. I will modify it to something that does not belong to my httpd server, so I need to pass it through the proxy module (my guess ;). I can't use either the static ProxyPass or ProxyReversePass, because the host will be modified dynamically and it will depend on what is called and substitute it from the database call. It wasn't a big deal to catch on the Host: (well, I may also need to look for something like GET http://blablabla.com/, but this is not the highest priority now). I have created a new HEAP bucket, put it instead of an original one, however, a) it looks to me that Apache makes a call and gives an error saying file wasn't found, however the Web page displayed is the correct one, like not being rewritten, and the httpd child crashes; and b) I need to send it to proxy somehow and pass the call to it. I am not very good on concept, my book on Apache modules is still on the way, but I'd very appreciate any hints on this. Thank you. I'd very thankful for cc: me as well. I think you may perhaps be going about this the wrong way. One can cause a request to be proxied by doing something like the following. This example uses mod_python, but could be done in C code or mod_perl as well. import posixpath from mod_python import apache def fixuphandler(req): if req.proxyreq: return apache.DECLINED normalised_uri = posixpath.normpath(req.uri) if normalised_uri: if normalised_uri != '/' and req.uri[-1] == '/': normalised_uri += '/' length = len(req.filename) length -= len(req.hlist.directory) - 1 length += len(req.path_info or '') baseurl = normalised_uri[:-length] path = normalised_uri[len(baseurl):] # THIS IS THE IMPORTANT BIT WHICH SETS UP PROXY. req.proxyreq = apache.PROXYREQ_REVERSE req.uri = 'http://www.dscpl.com.au' + path req.filename = 'proxy:%s' % req.uri req.handler = 'proxy-server' return apache.OK If you didn't want to proxy a particular request, just return DECLINED when you know so. Graham
Re: Question: how to change the request in input filter and pass it to proxy
This technique is taken from modules/proxy/mod_proxy.c in Apache source code. See the proxy_detect() function in that file for a C code example. One could change request headers on way through in same handler function as setup the proxy. Still need an output filter if you want to change handlers in response. I haven't used input/output filters that modify headers, so can't comment on that. Graham On 03/04/2008, Olexandr Prokhorenko [EMAIL PROTECTED] wrote: Hi, Do I understand you right and you're proposing to have just an Apache module (not a hook on either output or input filter) and modify the request then? I'd be very thankful if you can point me to any typical C code example doing that. I'm not very good at Python and never used to code with it. While I think that I understand what you're talking about, I'd be much comfortable with being able to sneak at the example ;) What I will also need is to rewrite cookies. Will I be able to do that this way as well? I decided to try on input filter just because I thought I may get in troubles rewriting the cookies. I'll also need to modify the proxy response, so it's a place for output filter, isn't it? Thanks, your reply was very quick. On Wed, Apr 2, 2008 at 9:39 PM, Graham Dumpleton [EMAIL PROTECTED] wrote: On 03/04/2008, Olexandr Prokhorenko [EMAIL PROTECTED] wrote: Hi everyone, I am working on the input filter which is going to catch on input requests, find the bucket with Host: , modify it and pass it through. I will modify it to something that does not belong to my httpd server, so I need to pass it through the proxy module (my guess ;). I can't use either the static ProxyPass or ProxyReversePass, because the host will be modified dynamically and it will depend on what is called and substitute it from the database call. It wasn't a big deal to catch on the Host: (well, I may also need to look for something like GET http://blablabla.com/, but this is not the highest priority now). I have created a new HEAP bucket, put it instead of an original one, however, a) it looks to me that Apache makes a call and gives an error saying file wasn't found, however the Web page displayed is the correct one, like not being rewritten, and the httpd child crashes; and b) I need to send it to proxy somehow and pass the call to it. I am not very good on concept, my book on Apache modules is still on the way, but I'd very appreciate any hints on this. Thank you. I'd very thankful for cc: me as well. I think you may perhaps be going about this the wrong way. One can cause a request to be proxied by doing something like the following. This example uses mod_python, but could be done in C code or mod_perl as well. import posixpath from mod_python import apache def fixuphandler(req): if req.proxyreq: return apache.DECLINED normalised_uri = posixpath.normpath(req.uri) if normalised_uri: if normalised_uri != '/' and req.uri[-1] == '/': normalised_uri += '/' length = len(req.filename) length -= len(req.hlist.directory) - 1 length += len(req.path_info or '') baseurl = normalised_uri[:-length] path = normalised_uri[len(baseurl):] # THIS IS THE IMPORTANT BIT WHICH SETS UP PROXY. req.proxyreq = apache.PROXYREQ_REVERSE req.uri = 'http://www.dscpl.com.au' + path req.filename = 'proxy:%s' % req.uri req.handler = 'proxy-server' return apache.OK If you didn't want to proxy a particular request, just return DECLINED when you know so. Graham -- Alexander Prohorenko.
Re: Dynamic configuration for the hackathon?
On Mar 31, 2008, at 13:31, Paul Querna wrote:
Just look at SSLRequire, Rewrite*, MPM Process/Thread Management,
Filter chaining, large Auth{N,Z} chains, and more.
Imagine them not sucking.
That would be lovely. Truly.
--
Happiness isn't something you experience; it's something you remember.
Oscar Levant
Re: Dynamic configuration for the hackathon?
On Mar 31, 2008, at 13:46, Issac Goldstand wrote: Make mod_wombat a standard module and part of the default moduleset May I request, if mod_wombat becomes a standard module, that it be given a name not quite so calculated to make the newbie disable it without a second glance. I mean, wombats are cute and all, and it's a delightful name, but nobody knows what it means. -- Whatever you do will be insignificant, but it is very important that you do it. Mahatma Ghandi
Re: Dynamic configuration for the hackathon?
On 4/2/08 8:44 AM, Rich Bowen [EMAIL PROTECTED] wrote: May I request, if mod_wombat becomes a standard module, that it be given a name not quite so calculated to make the newbie disable it without a second glance. I think the reason wombat was chosen is because mod_lua was taken. In reality, I suppose there should be a base lua module, then a configuration module based upon it and a hook handler module based upon it as well. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: Dynamic configuration for the hackathon?
There's a couple of conflicting demands by our users, and spending time on the users mailing list and on the IRC channel is a great way to see this first-hand. They don't want to learn a new syntax. And they want a new syntax that lets them do what they mean. And they're very frustrated when they can't do things that are obviously what everyone wants, and have to resort to mod_rewrite. Now, I'm very fond of mod_rewrite, because, after all, I wrote a book, and royalties from that book buy me my toys. But the time spent answering the same questions again and again on IRC lead me to believe that there are certain features that would gain us a lot of appreciation from our users - the folks who, at least to me, make this stuff worth doing. Easy for me to say, since I just document what the rest of you guys actually do. I recognize that it looks easy from the cheap seats. Virtual hosts are just one example of something that's amazingly hard (for beginners) to get right, and very easy to get wrong. And when it's wrong, it's unpredictably wrong, in ways that are hard to anticipate. On Mar 26, 2008, at 09:06, Nick Kew wrote: There seems to be a demand for dynamic per-request configuration, as evidenced by the number of users hacking it with mod_rewrite, and the other very limited tools available. Modern mod_rewrite usage commonly looks like programming, but it's not designed as a programming language. Result: confused and frustrated users. ... if [some-per-request-expr] Directives applicable per-request (anything, subject to per-directive context checking) /if ++1. This would solve an enormous number of the user problems that we experience on the help channels, which, I have to assume, are but the tip of the iceberg of problems experienced out there in the real world. It's amazing, sometimes, what absurd lengths folks have to go to, to solve the problems that they've created. A noble objective: render mod_rewrite obsolete :-) ++1 -- What the world needs is more geniuses with humility, there are so few of us left. Oscar Levant
Re: Dynamic configuration for the hackathon?
Issac Goldstand wrote: We're not talking about fresh users, we're talking about existing users. Fresh users have to deal with one learning curve or another anyway. I'm not talking about fresh users either. Matt
Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?]
Akins, Brian wrote: The biggest problems I have with current system are: -Every module does things differently Within limits this will remain true. But we are missing a host of very trivial simplifications for the casual module developer, and reinvent the same wheel module after module. I'm going to propose some changes to the default TAKE[0-9]+ macro and support functions to illustrate how much more useful these can be, and offer some new functions that make it really simple to * define constraints (an int, sure, but in what range?) * tag default-value, and error out if a non-default value is replaced by the user (e.g. LogLevel debug LogLevel error later on) -No real per-request configuration. Some modules use env to do some of this. ixnay on the run-time intensive, slow down the server sorts of changes. httpd continues to become slower as it becomes more powerful. I know you are the first one to raise your hand and point out when we are doing too much processing for too simple a request. Isn't this what modules are for? Perhaps you could elaborate? -I have to write a good bit of code before a module is configurable. (I'm lazy. Very lazy.) Agreed - see my first point. One interesting point; why do we keep per-server and per-dir sections? Perhaps it's time for a single simpler-to-use mechanic which can represent either or both (essentially deprecate per-server in 3.0). If we do what niq suggests (which, if we stick with current config system is fine) is that it just adds another layer on top of all the existing issues. With lua, for example you could make modules Lua modules... Maybe could do same in perl?? That's why I'm not a fan of all lua all the time. But to do what we all want, I bet we'll need to refine the config API, and simplify it for adding pluggable semantic engines (lua, perl, simply 'sed' etc). My opinion (which is worthless, I know) is to pick one way and do it. Lua is easy to learn and satisfies most (all?) of our requirements. And if Brian M. and I can learn it, anyone can ;) Most importantly, if I am building an embedded httpd, I don't want all of this extra crap. httpd was famous for how lean it could be, are we all ready to throw out that advantage?
Re: Dynamic configuration for the hackathon?
Graham Leggett wrote: Jim Jagielski wrote: This reminds me: a serf BOF or session would, I think, go over quite well :) A question that has been on my mind for a bit, is what does serf intend to replace, and why is it better?. The impression I have so far is that somehow what we have now is suboptimal, and that serf somehow does it better, but exactly what is suboptimal, and exactly how serf does it better has yet to be clarified. Someone please consider offering a title/abstract/speaker/bio on a fast paced introduction to the advantages of serf as a 15 minute FFT preso, so that we can all understand the answers to Graham's questions. [EMAIL PROTECTED] - for either wed or thurs afternoon.
Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?]
William A. Rowe, Jr. wrote: -I have to write a good bit of code before a module is configurable. (I'm lazy. Very lazy.) Agreed - see my first point. One interesting point; why do we keep per-server and per-dir sections? Perhaps it's time for a single simpler-to-use mechanic which can represent either or both (essentially deprecate per-server in 3.0). I'm pondering this... if we drop per-server ... yet retain the ability for authors to factor their config info into related config sections... ... we could divide the frequently-merged and infrequently-merged options into two or more groups; the overall merge calls would run more quickly, but the flexibility would be greatly enhanced. Override-able -document_root, anyone? Bill
Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?]
William A. Rowe, Jr. wrote: William A. Rowe, Jr. wrote: -I have to write a good bit of code before a module is configurable. (I'm lazy. Very lazy.) Agreed - see my first point. One interesting point; why do we keep per-server and per-dir sections? Perhaps it's time for a single simpler-to-use mechanic which can represent either or both (essentially deprecate per-server in 3.0). I'm pondering this... if we drop per-server ... yet retain the ability for authors to factor their config info into related config sections... ... we could divide the frequently-merged and infrequently-merged options into two or more groups; the overall merge calls would run more quickly, but the flexibility would be greatly enhanced. Override-able -document_root, anyone? And taking this one step further - addressing issues such as the fact that we all want certain merged-sections (e.g. vhosts) to be run as root early in the process, but be flexible enough to override a bit later on... ... if we had a config finalize, modules who were prepared to declare their config (e.g. mod_vhost declaring the per-host directory merges completed) then as-root, we can finish these out, opening logs with full privileges. Other merges will happen at run time (or be optimized when we can accomplish this) per-request. It's not looking trivial, but it seems doable.
