Re: GA
On 19 Mar 2011, at 00:02, Dan Poirier wrote: > At some point, do we declare a feature-freeze for what will be 2.4.0? Features can be added during a release. We will of course need an MMN-major freeze, which is the branch's promise of API/ABI back-compatibility. But we can still also add to the API provided we don't break anything. -- Nick Kew
Re: GA
On Fri. 2011-03-18 at 04:01 PM EDT, Jim Jagielski wrote: > My hopes are that if people are really wanting to invent and collaborate > on cool stuff, that they don't wait until a f2f event that the vast > majority of current httpd developers will not be attending and > will instead try to start stuff now-ish in hopes of getting a > GA out sooner rather than changing things so much that any > momentum achieved up to now is wasted by the addition of lots > of cool stuff that requires substantial vetting and thus causing > yet more delays on a release that has already been long enough > already thank you. At some point, do we declare a feature-freeze for what will be 2.4.0?
Re: mod_fcgid in httpd tarball?
On March 18, 2011 18:07 , "William A. Rowe Jr." wrote: It seems like mod_fcgid has made huge progress and is now in a much more stable bugfix epoch of it's life, similar to how mod_proxy had progressed when development was kicked out of core for major http/1.1 rework, and brought back in when a vast percentage of it's bugs had been addressed. Do we want to introduce mod_fcgid now into httpd 2.3.x for the next beta? For what it's worth, on the systems I'm deploying, I'm using mod_proxy_fcgi and putting in as much effort as necessary to fix any bugs, add features I need to it, etc., simply because mod_proxy_fcgi is a core module, while mod_fcgid is not. If mod_fcgid were in core, I may have wound up putting the effort there instead. (I say "may have" because I've come to think that mod_proxy_fcgi is actually a better choice for my particular needs, anyway). -- Mark Montague m...@catseye.org
mod_fcgid in httpd tarball?
It seems like mod_fcgid has made huge progress and is now in a much more stable bugfix epoch of it's life, similar to how mod_proxy had progressed when development was kicked out of core for major http/1.1 rework, and brought back in when a vast percentage of it's bugs had been addressed. Do we want to introduce mod_fcgid now into httpd 2.3.x for the next beta?
Adding ProxyErrorOverride support to mod_proxy_fcgi
I've created a patch to add support for the ProxyErrorOverride directive to mod_proxy_fcgi: https://issues.apache.org/bugzilla/show_bug.cgi?id=50913 Could someone review this patch, please, and get back to me with feedback and/or requests for changes? It's not important to me to have this functionality in 2.4, per se, but I'd like to address any concerns while everything is still relatively fresh in my mind. Many thanks! -- Mark Montague m...@catseye.org
Re: PHP5.3.6
On 3/18/2011 9:24 AM, Rich Bowen wrote: > I wanted to be sure that folks are aware of what's going on in the > Windows/PHP world. I know that, in one sense, it's not our problem, but it > *feels* like our problem to me, and to many of our users. Quite honestly, this leaves me with a taste to simply drop Windows builds altogether, and let the competing groups all prove up their own solutions. (including PHP, if they had the sense to ship an httpd build of their choice). This is little different than the competing binary builds for linux. There is an argument for, and available packages to install an entire lamp stack at once. They can do this because licensing the AL+MIT+GPL bits together is no issue to them. In reality, there's next to no reason to load PHP in process, I know of several engineers who have profiled the system load of in process mod_php vs. mod_fcgid with appropriately sized pools of php single processes with no threading. Very few deployments merit a 1:1 allocation of php workers to httpd workers, and this will become more striking as we move forward towards more asynch models. Of course a smaller number of single threaded php workers always wins, because PHP threading has reasonably high mutex contention, although I'm aware that the BDfL of php on win32 strongly disagrees with such results. But keep in mind, mod_perl and mod_python also suffer these issues, and they are interlocked into particular msvc runtimes that ActiveState, strawberry perl and others had elected. Even within their current shipping products, at any given time ActiveState perl and python are generally built with a different msvc flavor. Interesting for PHP to join the effort to further fragment the picture, today. (Yes, strawberry perl is an msys based build, but one that links in msvcr80). As I noted, switching now to VC9 when VC10 has been out for some time now is ass backwards. Within months [some 1 to 3 of them] there will be a finished 2.4.0 (which will be waiting for PHP binaries). If I go to the trouble of even offering some binaries, they certainly won't be using an already stale toolchain. The only sensible alternatives seem to be MSYS (and there too there is a question of which msvcrt version) or Mladen's proposal to stay with msvcrt, which I'm almost favoring right now.
Re: GA
On 3/18/2011 3:01 PM, Jim Jagielski wrote: > > My hopes are that if people are really wanting to invent and collaborate > on cool stuff, that they don't wait until a f2f event that the vast > majority of current httpd developers will not be attending and > will instead try to start stuff now-ish in hopes of getting a > GA out sooner rather than changing things so much that any > momentum achieved up to now is wasted by the addition of lots > of cool stuff that requires substantial vetting and thus causing > yet more delays on a release that has already been long enough > already thank you. And of course, there is an argument that if the 'final' improvements are picked up by a late April beta, whomever makes it to wicklow can start looking at what should be in httpd 3.0, even as 2.4 is introduced to the world :)
Re: GA
On Mar 17, 2011, at 4:40 PM, William A. Rowe Jr. wrote: > On 3/17/2011 1:31 PM, Jim Jagielski wrote: >> >> On Mar 17, 2011, at 11:34 AM, Jeff Trawick wrote: >> >>> On Fri, Mar 11, 2011 at 5:00 PM, Stefan Fritsch wrote: On Tuesday 01 March 2011, Jim Jagielski wrote: > This is our first Beta release; Based on the feedback and result > from this Beta, the hope is to push for a GA by the end of > March (2011)! FWIW, I would prefer another beta in April and tagging GA at or directly after the hackathon at Knockree (mid-May). There are still a number of things I want to have in 2.4 but I won't have much time in March. >>> >>> That sounds reasonable to me, but then I have my own little project >>> I'd like to finish up in time for the next beta :) >>> >> >> My plan is to have another beta the end of March, another >> in April and GA in May (at the latest)... > > Well, if we presume that people will invent and collaborate to refine > some "cool stuff" at Wicklow, it isn't unreasonable to guess that such > a tarball would still be beta and need several weeks of a "large group" > of final testers and some bug fixes to be realistically be "the best > available version" and more robust than 2.2.17 in June. I will vote > against declaring 'ga' any taraball which can't meet that self-described > label that we've assign to every general release for over a dozen years :) > My hopes are that if people are really wanting to invent and collaborate on cool stuff, that they don't wait until a f2f event that the vast majority of current httpd developers will not be attending and will instead try to start stuff now-ish in hopes of getting a GA out sooner rather than changing things so much that any momentum achieved up to now is wasted by the addition of lots of cool stuff that requires substantial vetting and thus causing yet more delays on a release that has already been long enough already thank you. *grin*
Re: PHP5.3.6
On Mar 18, 2011, at 12:07 PM, Mladen Turk wrote: > On 03/18/2011 04:55 PM, Rich Bowen wrote: >> >> On Mar 18, 2011, at 11:48 AM, Mladen Turk wrote: >> >>> On 03/18/2011 04:43 PM, Jeff Trawick wrote: what if we add text to our download that says that official PHP binaries for Windows starting with 5.3.6 no longer work with our stable-ABI builds >>> >>> +1 >> >> Doing that without suggesting an alternative seems discourteous both to >> these Windows users and to the PHP community. >> > > Alternative would be "We are looking for a solution". > We don't need to give up before even trying. > > I gave the alternative by using winddk compilers. > If compiled using those tools it works perfectly with both old and new php > versions. > > Look at thread few weeks ago. > Bill said he will use VS2010, so given that PHP uses VS2008 > we are again in endless loop of catching one other's version. > > Like I suggested, we could avoid linking to msvcrtXX.dll > which will allow any third party plug-in to work seamlessly. If that's something that we're actively moving towards, that would be great. Thanks. -- Rich Bowen rbo...@rcbowen.com
Re: AuthN only once per request instead once every subrequest
Thank you for your prompt reply! And your two fine suggestions.
On 18/03/11 11:45, Nick Kew wrote:
> On 18 Mar 2011, at 10:22, PlagiaTUM wrote:
>> With a little profiling we found out that authentication is done
>> for every subrequest, of which mod_autoindex uses plenty.
>
> You have two good solutions to that. Either use the ShowForbidden
> option to mod_autoindex, or use mod_authn_socache.
We did not know about mod_authn_socache; It is not in 2.2. Sorry for not
looking more thoroughly. Sounds like a sensible addition from our
perspective!
For our case, we cannot confirm that ShowForbidden helps at all.
The mod_autoindex code (looking at 2.2 trunk) looks like the subrequest
is done anyways; with ShowForbidden it is just ignoring its return value.
We can create a patch for mod_autoindex if you'd like us to.
We were hoping to fix the issue a level below that, possibly catching
more than just the mod_autoindex module in the process.
>> There is some logic in ap_process_request_internal() that should
>> optimize these out; however, it does not work for us. The
>> comparison (r->main->per_dir_config == r->per_dir_config) never
>> succeeds as ap_merge_per_dir_configs() always returns a new
>> configuration vector.
>
> It does if the configurations to r and r->main are not the same.
Yes, but can the pointer ever be the same?
request.c (2.2 trunk), lines 169ff:
> /* Reset to the server default config prior to running
> map_to_storage */ r->per_dir_config = r->server->lookup_defaults;
Just a page down of that file, the comparison is done:
same file, line 204
> if (r->prev && (r->prev->per_dir_config == r->per_dir_config)) {
Also, the comments in the source code above indicate that the pointer
equality is reached by having ``optimized'' _walk() functions:
> /* Skip authn/authz if the parent or prior request passed the
> authn/authz, * and that configuration didn't change (this requires
> optimized _walk() * functions in map_to_storage that use the same
> merge results given * identical input.)
That sounded like a fruitful way to go, but we didn't understand what to
do. Are these _walk()s ``optimized'' already?
Please excuse our being so stubborn about this.
Greetings from Munich!
--
PlagiaTUM is Heike Muni, Thomas Kittel and Florian Sesser.
Messing with others' code when we should be studying.
2.4 API changes for AAA
after gathering pages of scribbles from comparing 2.2.x/modules<->2.3.x/modules and 2.2.x/include<->2.3.x/include for API changes and trying to describe as many as I could, I'm left with a list of things to research further: check_user_id->check_authn access_checker->check_access auth_checker->check_authz AUTHN_PROVIDER_VERSION? note_basic_auth_failure ap_register_provider->ap_register_auth_provider ap_authn_cache_store ap_hook_auth_checker->register_auth_provider access_checker_ex What's the big picture here? Is it something like IF YOU USE THE UGLY LEGACY HTTPD 1.3/2.0 MODEL: * dudette, your code still works (but shame on you for not using the 2.2 provider framework) * you may be interested in switching to the 2.4 provider framework, which allows for XXX,YYY,ZZZ * you may be interested in these new features: AAA,BBB,CCC If you use the httpd 2.2 provider framework (ponies and rainbows): * change1 (e.g., "0"->AUTHN_PROVIDER_VERSION) * change2 * ... * changen * you may be interested in these new features: AAA,BBB,CCC hints?
Re: PHP5.3.6
On 03/18/2011 05:19 PM, Graham Dumpleton wrote: On 18 March 2011 07:24, Rich Bowen wrote: If I read this right, this is a similar issue to what we have in the Python world with some Python extension modules on Windows. One discussion thread about it can be found at: http://psycopg.lighthouseapp.com/projects/62710/tickets/20 Scan down towards end of discussion for overview. I don't think that relates to the original problem. Here, php crashes the httpd caused by msvcrt incompatibilities. Well, it actually asserts the 'Runtime initialization'. Regards -- ^TM
Re: PHP5.3.6
On 18 March 2011 07:24, Rich Bowen wrote: > I wanted to be sure that folks are aware of what's going on in the > Windows/PHP world. I know that, in one sense, it's not our problem, but it > *feels* like our problem to me, and to many of our users. > > PHP5.3.6 was just released, and the Windows binaries are built with VC9, > meaning that it won't work with our Windows binaries. I know that it's been > discussed before, and there's a plan to move to VC9, but as of last week, the > official PHP build doesn't run with the official Apache httpd build. The PHP > website recommends that folks use the Apache Lounge build. > > This sucks. > > It sucks that our users have to jump through additional hoops. It sucks even > more that there wasn't (or at least, it appears to me that there wasn't) > conversation between the two communities prior to this happening. The folks > in php-land are aware that it's a problem, but don't see to really think that > it's *their* problem. For our part, we seem to be unaware that anything > happened. > > I don't know that the relationship between Apache httpd and php communities > is anybody's *fault*, but it's long struck me as a great shame that there > isn't closer cooperation between the two communities. > > I'm not sure exactly what I'm suggesting we do about this. It would be nice > if we could provide binaries built with VC9, or if we could recommend on the > download site that people get binaries from ApacheLounge. I don't know if > either of these is really an option. How would folks feel about our download > site encouraging folks to use ApacheLounge's version of 2.2? I suspect that > there'd be some resistance to this, based on our previous interactions with > them. > > I have a foot in the documentation team of both projects, so I tend to hear > both sides of the conversation at least from that perspective. I'd like for > us to be more proactive about strengthening the community bond between us and > what is probably the most important third-party Apache httpd module. There > seems to be a pretty strong "they don't ever listen to us" attitude on both > sides, and I'm not sure that it's really warranted. If I read this right, this is a similar issue to what we have in the Python world with some Python extension modules on Windows. One discussion thread about it can be found at: http://psycopg.lighthouseapp.com/projects/62710/tickets/20 Scan down towards end of discussion for overview. They have solved this problem in Python world by having the affected package reinsert the missing VC runtime reference into the manifest file used with the extension. So, as far as I can see, PHP has a way of solving this themselves without requiring a change in Apache. Graham
Re: PHP5.3.6
On 03/18/2011 04:55 PM, Rich Bowen wrote: On Mar 18, 2011, at 11:48 AM, Mladen Turk wrote: On 03/18/2011 04:43 PM, Jeff Trawick wrote: what if we add text to our download that says that official PHP binaries for Windows starting with 5.3.6 no longer work with our stable-ABI builds +1 Doing that without suggesting an alternative seems discourteous both to these Windows users and to the PHP community. Alternative would be "We are looking for a solution". We don't need to give up before even trying. I gave the alternative by using winddk compilers. If compiled using those tools it works perfectly with both old and new php versions. Look at thread few weeks ago. Bill said he will use VS2010, so given that PHP uses VS2008 we are again in endless loop of catching one other's version. Like I suggested, we could avoid linking to msvcrtXX.dll which will allow any third party plug-in to work seamlessly. Regards -- ^TM
Re: PHP5.3.6
On Mar 18, 2011, at 11:48 AM, Mladen Turk wrote: > On 03/18/2011 04:43 PM, Jeff Trawick wrote: >> >> what if we add text to our download that says that official PHP >> binaries for Windows starting with 5.3.6 no longer work with our >> stable-ABI builds >> > > +1 Doing that without suggesting an alternative seems discourteous both to these Windows users and to the PHP community. -- Rich Bowen rbo...@rcbowen.com
Re: PHP5.3.6
On 03/18/2011 04:43 PM, Jeff Trawick wrote: what if we add text to our download that says that official PHP binaries for Windows starting with 5.3.6 no longer work with our stable-ABI builds +1 Regards -- ^TM
Re: PHP5.3.6
On Fri, Mar 18, 2011 at 11:12 AM, Rich Bowen wrote:
>
> On Mar 18, 2011, at 10:55 AM, Jeff Trawick wrote:
>
>>
>> I don't think we should ever point to third party httpd downloads.
>> Let those offering binaries compete in the same way as Ubuntu, Fedora,
>> etc.
>> I think in general that the Apache-on-Windows user community offers up
>> a relatively small amount of sacrifice (contributed effort per size of
>> community) at the same time that the platform has a large number of
>> technical considerations, and I cannot suggest that we (really, Bill
>> and tiny number of others) do more work on their behalf.
>
> I'm not suggesting that Bill do any more on their behalf. I'm suggesting that
> we embrace the huge effort that Stefan and the ApacheLounge folks have done,
> and direct people there. It seems that everybody stands to benefit if we
> improve relations with that community, or, at the very least, acknowledge
> their existence.
>
> What would it take, from our side or from Stefan's, to make it ok for us to
> say "go here for Windows binaries"? It surely seems that this would be a big
> win for both of us.
why not go to apachefriends and get Apache and PHP built/tested
together and somewhat integrated? where does it end, and why pick
winners? heck, maybe I lose my job tomorrow and decide I want to sell
ads on my own binary download pages; can I get a preferred link? I'll
even see if phpinfo() works
the people downloading php 5.3.6 binaries already got the hint to go
to ApacheLounge, right?
what if we add text to our download that says that official PHP
binaries for Windows starting with 5.3.6 no longer work with our
stable-ABI builds
>> For open source on Windows in general, I think changes to make it more
>> practical for "normal" users to build open source is what will
>> ultimately improve the overall Windows situation (it is an anomaly
>> that we have such a discussion of binaries), as it enables a more
>> fruitful conversation ("can you try this patch?" vs. getting stuck at
>> "you gave me this binary and it fails") and will facilitate the
>> involvement of more would-be developers. I understand that MS has
>> done a lot of work to make it more feasible to build PHP + extensions
>> on Windows. This doesn't help at all the VC6 issue, but it is a big
>> improvement for the long term. (I wonder if MinGW support by the
>> various projects is viable for random users, or if a lot more effort
>> is required to make it smoother.)
>
> That sounds good, I suppose, but doesn't actually help any of our actual
> customers today, or any foreseeable tomorrow.
I guess the "Give a man a fish..." spiel wouldn't go over too well right now...
Re: PHP5.3.6
On 03/18/2011 04:12 PM, Rich Bowen wrote: On Mar 18, 2011, at 10:55 AM, Jeff Trawick wrote: > What would it take, from our side or from Stefan's, to make it ok for us to say "go here for Windows binaries"? It surely seems that this would be a big win for both of us. AFAICT they do not produce .msi installer, only .zip files However I have httpd binaries linked to msvcrt.dll and build by VS2008 which offer the highest possible compatibility. See: http://www.syndicateofideas.com/posts/fighting-the-msvcrt-dll-hell It uses the latest WindowsDDK compilers which Microsoft is using to compile system components. I also use this system for quite some time for producing commons daemon and few other windows binaries. Regards -- ^TM
Re: PHP5.3.6
On Mar 18, 2011, at 10:55 AM, Jeff Trawick wrote:
>
> I don't think we should ever point to third party httpd downloads.
> Let those offering binaries compete in the same way as Ubuntu, Fedora,
> etc.
> I think in general that the Apache-on-Windows user community offers up
> a relatively small amount of sacrifice (contributed effort per size of
> community) at the same time that the platform has a large number of
> technical considerations, and I cannot suggest that we (really, Bill
> and tiny number of others) do more work on their behalf.
I'm not suggesting that Bill do any more on their behalf. I'm suggesting that
we embrace the huge effort that Stefan and the ApacheLounge folks have done,
and direct people there. It seems that everybody stands to benefit if we
improve relations with that community, or, at the very least, acknowledge their
existence.
What would it take, from our side or from Stefan's, to make it ok for us to say
"go here for Windows binaries"? It surely seems that this would be a big win
for both of us.
> For open source on Windows in general, I think changes to make it more
> practical for "normal" users to build open source is what will
> ultimately improve the overall Windows situation (it is an anomaly
> that we have such a discussion of binaries), as it enables a more
> fruitful conversation ("can you try this patch?" vs. getting stuck at
> "you gave me this binary and it fails") and will facilitate the
> involvement of more would-be developers. I understand that MS has
> done a lot of work to make it more feasible to build PHP + extensions
> on Windows. This doesn't help at all the VC6 issue, but it is a big
> improvement for the long term. (I wonder if MinGW support by the
> various projects is viable for random users, or if a lot more effort
> is required to make it smoother.)
That sounds good, I suppose, but doesn't actually help any of our actual
customers today, or any foreseeable tomorrow.
--
Rich Bowen
rbo...@rcbowen.com
Re: PHP5.3.6
On Fri, Mar 18, 2011 at 10:24 AM, Rich Bowen wrote:
> I wanted to be sure that folks are aware of what's going on in the
> Windows/PHP world. I know that, in one sense, it's not our problem, but it
> *feels* like our problem to me, and to many of our users.
>
> PHP5.3.6 was just released, and the Windows binaries are built with VC9,
> meaning that it won't work with our Windows binaries. I know that it's been
> discussed before, and there's a plan to move to VC9, but as of last week, the
> official PHP build doesn't run with the official Apache httpd build. The PHP
> website recommends that folks use the Apache Lounge build.
>
> This sucks.
>
> It sucks that our users have to jump through additional hoops. It sucks even
> more that there wasn't (or at least, it appears to me that there wasn't)
> conversation between the two communities prior to this happening. The folks
> in php-land are aware that it's a problem, but don't see to really think that
> it's *their* problem. For our part, we seem to be unaware that anything
> happened.
>
> I don't know that the relationship between Apache httpd and php communities
> is anybody's *fault*, but it's long struck me as a great shame that there
> isn't closer cooperation between the two communities.
>
> I'm not sure exactly what I'm suggesting we do about this. It would be nice
> if we could provide binaries built with VC9, or if we could recommend on the
> download site that people get binaries from ApacheLounge. I don't know if
> either of these is really an option. How would folks feel about our download
> site encouraging folks to use ApacheLounge's version of 2.2? I suspect that
> there'd be some resistance to this, based on our previous interactions with
> them.
>
> I have a foot in the documentation team of both projects, so I tend to hear
> both sides of the conversation at least from that perspective. I'd like for
> us to be more proactive about strengthening the community bond between us and
> what is probably the most important third-party Apache httpd module. There
> seems to be a pretty strong "they don't ever listen to us" attitude on both
> sides, and I'm not sure that it's really warranted.
I mostly agree with your sentiment.
I don't think we should ever point to third party httpd downloads.
Let those offering binaries compete in the same way as Ubuntu, Fedora,
etc.
I think in general that the Apache-on-Windows user community offers up
a relatively small amount of sacrifice (contributed effort per size of
community) at the same time that the platform has a large number of
technical considerations, and I cannot suggest that we (really, Bill
and tiny number of others) do more work on their behalf.
For open source on Windows in general, I think changes to make it more
practical for "normal" users to build open source is what will
ultimately improve the overall Windows situation (it is an anomaly
that we have such a discussion of binaries), as it enables a more
fruitful conversation ("can you try this patch?" vs. getting stuck at
"you gave me this binary and it fails") and will facilitate the
involvement of more would-be developers. I understand that MS has
done a lot of work to make it more feasible to build PHP + extensions
on Windows. This doesn't help at all the VC6 issue, but it is a big
improvement for the long term. (I wonder if MinGW support by the
various projects is viable for random users, or if a lot more effort
is required to make it smoother.)
Re: PHP5.3.6
Hey guys, I'm sort of new to this list ( been reading the emails for a while now). At the moment I would think it would be easiest to just add a note to the Apache Wikipedia page for the http server, maybe in the developer or PHP section. Sent from my Verizon Wireless Phone - Reply message - From: "Rich Bowen" Date: Fri, Mar 18, 2011 10:24 Subject: PHP5.3.6 To: I wanted to be sure that folks are aware of what's going on in the Windows/PHP world. I know that, in one sense, it's not our problem, but it *feels* like our problem to me, and to many of our users. PHP5.3.6 was just released, and the Windows binaries are built with VC9, meaning that it won't work with our Windows binaries. I know that it's been discussed before, and there's a plan to move to VC9, but as of last week, the official PHP build doesn't run with the official Apache httpd build. The PHP website recommends that folks use the Apache Lounge build. This sucks. It sucks that our users have to jump through additional hoops. It sucks even more that there wasn't (or at least, it appears to me that there wasn't) conversation between the two communities prior to this happening. The folks in php-land are aware that it's a problem, but don't see to really think that it's *their* problem. For our part, we seem to be unaware that anything happened. I don't know that the relationship between Apache httpd and php communities is anybody's *fault*, but it's long struck me as a great shame that there isn't closer cooperation between the two communities. I'm not sure exactly what I'm suggesting we do about this. It would be nice if we could provide binaries built with VC9, or if we could recommend on the download site that people get binaries from ApacheLounge. I don't know if either of these is really an option. How would folks feel about our download site encouraging folks to use ApacheLounge's version of 2.2? I suspect that there'd be some resistance to this, based on our previous interactions with them. I have a foot in the documentation team of both projects, so I tend to hear both sides of the conversation at least from that perspective. I'd like for us to be more proactive about strengthening the community bond between us and what is probably the most important third-party Apache httpd module. There seems to be a pretty strong "they don't ever listen to us" attitude on both sides, and I'm not sure that it's really warranted. -- Rich Bowen rbo...@rcbowen.com
PHP5.3.6
I wanted to be sure that folks are aware of what's going on in the Windows/PHP world. I know that, in one sense, it's not our problem, but it *feels* like our problem to me, and to many of our users. PHP5.3.6 was just released, and the Windows binaries are built with VC9, meaning that it won't work with our Windows binaries. I know that it's been discussed before, and there's a plan to move to VC9, but as of last week, the official PHP build doesn't run with the official Apache httpd build. The PHP website recommends that folks use the Apache Lounge build. This sucks. It sucks that our users have to jump through additional hoops. It sucks even more that there wasn't (or at least, it appears to me that there wasn't) conversation between the two communities prior to this happening. The folks in php-land are aware that it's a problem, but don't see to really think that it's *their* problem. For our part, we seem to be unaware that anything happened. I don't know that the relationship between Apache httpd and php communities is anybody's *fault*, but it's long struck me as a great shame that there isn't closer cooperation between the two communities. I'm not sure exactly what I'm suggesting we do about this. It would be nice if we could provide binaries built with VC9, or if we could recommend on the download site that people get binaries from ApacheLounge. I don't know if either of these is really an option. How would folks feel about our download site encouraging folks to use ApacheLounge's version of 2.2? I suspect that there'd be some resistance to this, based on our previous interactions with them. I have a foot in the documentation team of both projects, so I tend to hear both sides of the conversation at least from that perspective. I'd like for us to be more proactive about strengthening the community bond between us and what is probably the most important third-party Apache httpd module. There seems to be a pretty strong "they don't ever listen to us" attitude on both sides, and I'm not sure that it's really warranted. -- Rich Bowen rbo...@rcbowen.com
Re: can mod_auth_ldap expose user's DN in environment (for custom logs)?
On Wed, 02 Mar 2011 12:11:36 +0100 Guenter Knauf wrote: GK> Hi Ted, GK> Am 01.03.2011 21:06, schrieb Ted Zlatanov: >> Sorry if this has been discussed before. I couldn't find past mentions >> after searching the archives. If there's a better way than what I'm >> suggesting, please let me know. >> >> In addition to the user name I need the LDAP DN of the user in the >> custom log. That's available in mod_auth_ldap but not exposed. I >> propose to modify modules/ldap/util_ldap.c:uldap_cache_comparedn() to >> (optionally?) store the DN in a "LDAP_DN" environment variable which can >> then be shown in the custom log and used in other ways. GK> isnt AuthLDAPRemoteUserIsDN what you want? GK> http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html#authldapremoteuserisdn On Wed, 2 Mar 2011 06:45:53 -0500 Eric Covener wrote: EC> can you just add 'dn' to the end of AUTHLDAPURL and log AUTHENTICATE_DN? EC> http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html#exposed Both approaches were helpful. Thank you for your help! I posted once already and got rejected through Gmane, so I cc-ed the two followup posters directly in case this post doesn't make it either. Ted
Re: AuthN only once per request instead once every subrequest
On 18 Mar 2011, at 10:22, PlagiaTUM wrote: > Dear List! > > We are trying to use mod_autoindex on an access-restricted web server > with lots of directories. Our AuthN is costly (we are using > mod_auth_external). With ~ 700 directories, the generation of the index > takes > 1 minute. > > With a little profiling we found out that authentication is done for > every subrequest, of which mod_autoindex uses plenty. You have two good solutions to that. Either use the ShowForbidden option to mod_autoindex, or use mod_authn_socache. > There is some logic in ap_process_request_internal() that should > optimize these out; however, it does not work for us. The comparison > (r->main->per_dir_config == r->per_dir_config) never succeeds as > ap_merge_per_dir_configs() always returns a new configuration vector. It does if the configurations to r and r->main are not the same. > Cf. request.c lines 145ff (inside of ap_process_request_internal()) and > 466ff (ap_directory_walk()) and config.c lines 230ff > (ap_merge_per_dir_configs()). > > Why is it necessary to re-authenticate within a subrequest? > When the per_dir configuration has changed, AuthZ has of course to be > rechecked. AuthN, on the other hand, could be taken from the parent > request, where it already has been verified. What are we missing? There's nothing to stop the subrequest running off an entirely different AuthUserFile/equiv to the main request. -- Nick Kew Available for work, contract or permanent http://www.webthing.com/~nick/cv.html
AuthN only once per request instead once every subrequest
Dear List!
We are trying to use mod_autoindex on an access-restricted web server
with lots of directories. Our AuthN is costly (we are using
mod_auth_external). With ~ 700 directories, the generation of the index
takes > 1 minute.
With a little profiling we found out that authentication is done for
every subrequest, of which mod_autoindex uses plenty.
There is some logic in ap_process_request_internal() that should
optimize these out; however, it does not work for us. The comparison
(r->main->per_dir_config == r->per_dir_config) never succeeds as
ap_merge_per_dir_configs() always returns a new configuration vector.
Cf. request.c lines 145ff (inside of ap_process_request_internal()) and
466ff (ap_directory_walk()) and config.c lines 230ff
(ap_merge_per_dir_configs()).
Why is it necessary to re-authenticate within a subrequest?
When the per_dir configuration has changed, AuthZ has of course to be
rechecked. AuthN, on the other hand, could be taken from the parent
request, where it already has been verified. What are we missing?
With the attached patch (against 2.2.17), the page generation is down to
one AuthN process (ca. 2 seconds overall) on our machine.
The patch is meant for communication purposes only, to illustrate what
we are talking about. It is not intended to be a ready made solution to
the problem we found. To make our changes stand out, we also forwent
correct indentation.
We would have liked to include a check like ``if the user is the same as
in the parent request and it already has been AuthN'd'', but we don't
know the best way to do that.
A quick test with a .htaccess file showed that Access Restrictions are
still honored within a subrequest.
Thank you for your consideration and time!
PlagiaTUM
diff --git a/server/request.c b/server/request.c
index 1801cf7..4b30db7 100644
--- a/server/request.c
+++ b/server/request.c
@@ -170,7 +170,7 @@ AP_DECLARE(int) ap_process_request_internal(request_rec *r)
* functions in map_to_storage that use the same merge results given
* identical input.) If the config changes, we must re-auth.
*/
-if (r->main && (r->main->per_dir_config == r->per_dir_config)) {
+if (r->main) {
r->user = r->main->user;
r->ap_auth_type = r->main->ap_auth_type;
}
@@ -178,7 +178,7 @@ AP_DECLARE(int) ap_process_request_internal(request_rec *r)
r->user = r->prev->user;
r->ap_auth_type = r->prev->ap_auth_type;
}
-else {
+{
switch (ap_satisfies(r)) {
case SATISFY_ALL:
case SATISFY_NOSPEC:
@@ -187,8 +187,8 @@ AP_DECLARE(int) ap_process_request_internal(request_rec *r)
}
if (ap_some_auth_required(r)) {
-if (((access_status = ap_run_check_user_id(r)) != 0)
-|| !ap_auth_type(r)) {
+if (!r->user && (((access_status = ap_run_check_user_id(r)) != 0)
+|| !ap_auth_type(r))) {
return decl_die(access_status, ap_auth_type(r)
? "check user. Check your authn provider!"
: "perform authentication. AuthType not set!",
@@ -211,8 +211,8 @@ AP_DECLARE(int) ap_process_request_internal(request_rec *r)
return decl_die(access_status, "check access", r);
}
-if (((access_status = ap_run_check_user_id(r)) != 0)
-|| !ap_auth_type(r)) {
+if (!r->user && (((access_status = ap_run_check_user_id(r)) != 0)
+|| !ap_auth_type(r))) {
return decl_die(access_status, ap_auth_type(r)
? "check user. Check your authn provider!"
: "perform authentication. AuthType not set!",
