Re: mod_proxy_http2 windows build

2016-05-18 Thread Jan Ehrhardt 
William A Rowe Jr in gmane.comp.apache.devel (Wed, 18 May 2016 14:54:41
-0500):
>The .dsp files become irrelevant in this day and age, the legacy environment
>it maps to is entirely dead and beyond availability (snip)...

Yet they are still the preferred way of building Apache by the people at
Apachelounge. And the .mak files are preferred by Gregg at Apachehaus.

Jan

Re: mod_proxy_http2 windows build

2016-05-18 Thread William A Rowe Jr 
On Wed, May 18, 2016 at 10:58 AM, Michal Karm 
wrote:

> On 05/18/2016 05:24 PM, William A Rowe Jr wrote:
>
>> ... and .mak/.dep files in 2.4 branch, I'm on it today.
>>
>>
>> On Wed, May 18, 2016 at 10:09 AM, Stefan Eissing <
>> stefan.eiss...@greenbytes.de >
>> wrote:
>>
>> Reaching out to the knowledgable and always helpful Windows people:
>> do we
>> need a mod_proxy_http2.dsp in trunk/modules/http2 (and 2.4.x branch
>> for
>> next release)?
>>
>> Or perhaps to seize the opportunity to purge .dep/.mak and have a proper
> CMakeLists.txt instead? :)
>

As Stefan points out, that was already solved for the CMakeLists.txt...
if you consider it an 'improper' cmake implementation, I'm sure you can't
wait to post your patches to correct that.

Purging .dsp/.mak/.dep arrives with httpd 2.6/3.0.

We try not to be a$$es to our users as they upgrade from 2.2.31 to 2.2.32,
or from 2.4.20 to 2.4.21, so we ensure that the package remains buildable
from one subversion release to another... particularly because users often
pick up the latest subversion release to obtain security fixes, and we want
that transition from one to the next subversion release to involve as little
disruption as possible. This is across our users who are on windows, or
or linux, or any of a number of other architectures.

The .dsp files become irrelevant in this day and age, the legacy environment
it maps to is entirely dead and beyond availability, but our next chance to
fully
transition to cmake comes with the next major.minor version bump.

Task #85e57cec: Improve the Request Processing guide

2016-05-18 Thread Onder SEZGIN 
Hi,

I would like to contribute to the task.
Any guidance how i can do that is appreciated.

Cheers

Re: mod_proxy_http2 windows build

2016-05-18 Thread Stefan Eissing 
it should be in cmakelist in the apache svn. 

> Am 18.05.2016 um 17:58 schrieb Michal Karm :
> 
>> On 05/18/2016 05:24 PM, William A Rowe Jr wrote:
>> ... and .mak/.dep files in 2.4 branch, I'm on it today.
>> 
>> 
>> On Wed, May 18, 2016 at 10:09 AM, Stefan Eissing 
>> > wrote:
>> 
>>Reaching out to the knowledgable and always helpful Windows people: do we
>>need a mod_proxy_http2.dsp in trunk/modules/http2 (and 2.4.x branch for
>>next release)?
>> 
>>-Stefan
> Or perhaps to seize the opportunity to purge .dep/.mak and have a proper 
> CMakeLists.txt instead? :)
> 
> Michal Karm Babacek
> 
> -- 
> Sent from my Hosaka Ono-Sendai Cyberspace 7
>

Re: mod_proxy_http2 windows build

2016-05-18 Thread Michal Karm 

On 05/18/2016 05:24 PM, William A Rowe Jr wrote:

... and .mak/.dep files in 2.4 branch, I'm on it today.


On Wed, May 18, 2016 at 10:09 AM, Stefan Eissing > wrote:


Reaching out to the knowledgable and always helpful Windows people: do we
need a mod_proxy_http2.dsp in trunk/modules/http2 (and 2.4.x branch for
next release)?

-Stefan


Or perhaps to seize the opportunity to purge .dep/.mak and have a proper 
CMakeLists.txt instead? :)


Michal Karm Babacek

--
Sent from my Hosaka Ono-Sendai Cyberspace 7

Re: mod_proxy_http2 windows build

2016-05-18 Thread William A Rowe Jr 
... and .mak/.dep files in 2.4 branch, I'm on it today.


On Wed, May 18, 2016 at 10:09 AM, Stefan Eissing <
stefan.eiss...@greenbytes.de> wrote:

> Reaching out to the knowledgable and always helpful Windows people: do we
> need a mod_proxy_http2.dsp in trunk/modules/http2 (and 2.4.x branch for
> next release)?
>
> -Stefan

mod_proxy_http2 windows build

2016-05-18 Thread Stefan Eissing 
Reaching out to the knowledgable and always helpful Windows people: do we need 
a mod_proxy_http2.dsp in trunk/modules/http2 (and 2.4.x branch for next 
release)?

-Stefan

Re: mod_proxy_hcheck backport

2016-05-18 Thread Jim Jagielski 
Seems like adding that directly to the module itself makes the most sense. 
Later versions
will allow for using Provider API to make it easier to add various checks,

On 2016-05-17 05:17, Stefan Eissing  wrote: 
> Jim,
> 
> how do you see the possibility of other proxy modules providing their own hc? 
> HTTP/2 has this nice PING frame that is intended for exactly this.
> 
> Cheers,
>  Stefan
> 
> PS. Btw. it's accepted for backport, left the actual work for you...
> 
> > Am 17.05.2016 um 12:41 schrieb Jim Jagielski :
> > 
> > 
> >> On May 16, 2016, at 3:37 PM, Daniel Ruggeri  wrote:
> >> 
> >> On 5/16/2016 8:19 AM, Jim Jagielski wrote:
> >>> THANKS! This feature seemed to cause a lot of buzz @ ApacheCon so
> >>> would be
> >> 
> >> I believe I heard and/or used the term "sexy" at least once to describe
> >> it ;-)
> >> 
> >> 
> >> On 5/16/2016 8:19 AM, Jim Jagielski wrote:
> >>> Hmmm... The balancer-manager page does display the configured
> >>> values for 'hcpasses' and 'hcfails' as well as the current count
> >>> of passes/fails. Is that sufficient?
> >> 
> >> Yeah - didn't think about that. It'd be fine for my purposes. It could
> >> be a PITA if someone is monitoring for a specific string like
> >> "transitive" or "fail", but it's probably not worth monkeying with.
> >> 
> > 
> > Yeah... let's mull this over and see what makes the most sense.
> > 
> 
>

Improving logs to make AUTH_DENIES easy to understand and fix

2016-05-18 Thread Tianyin Xu 
Hi all,

I've been using httpd's authentication & authorization modules for several
weeks. Compared to many other modules I used in the past, the debugging of
"auth deny" issues (caused by these modules) is really a pain in the ass.
The key problem is that httpd often does not tell *why* certain requests
are denied, but only give a very general message like,
"[auth_basic:error] AH01617: user tixu: authentication failure for "/":
"
"[authz_core:error] AH01631: user tixu: authorization failure for "/":"

In many cases, these two log messages are the only ones available for
debugging. But they really do not pinpoint the reason beneath the
authn/authz failures. Yes, these two logs are printed in `mod_auth_basic`
and `mod_authz_core` where the authn/authz results from different providers
are aggregated.

Even worse, things got much more complicated and hard to debug when
multiple authn/authz providers are applied (e.g., file + ldap + ssl). In
fact, these're not uncommon,
https://httpd.apache.org/docs/2.4/howto/auth.html#multprovider
Note that, with AH01617 and AH01631, we can't even know which module
actually denied the request!

Certainly, there are awesome auth modules like `mod_authz_owner` and
`mod_authz_dbm` which have excellent logging ---before each AUTH_DENIED, it
has error logs to pinpoint the precise reason (checkout
`fileowner_check_authorization(..)` in `mod_authz_owner.c` and
`dbmgroup_check_authorization(..)` in `mod_authz_dbm.c`).
https://github.com/apache/httpd/blob/trunk/modules/aaa/mod_authz_owner.c
https://github.com/apache/httpd/blob/trunk/modules/aaa/mod_authz_dbm.c

With such precise log msgs, we sysadmins can understand the problems and
take actions immediately.

Unfortunately, in many other cases, the authn/z modules keep silent and
thus ending with AH01617 and AH01631. The following shows two of the
examples,

static authz_status ssl_authz_require_ssl_check(...) { /*
ssl_engine_kernel.c */
...
if (ssl)
return AUTHZ_GRANTED;
else
return AUTHZ_DENIED;
}

and

static authz_status dbdgroup_check_authorization(...) { /* mod_authz_dbd.c
*/
while (...) {
...
return AUTHZ_GRANTED;
}
return AUTHZ_DENIED;
}

Such cases are not rare, but prevalent across several authn/authz modules.

I propose to apply the same good practices (such as mod_authz_owner &
mod_authz_dbm) to all the authn/authz modules. Basically, I want to add log
messages before each AUTHN/Z_DENIES to pinpoint:

1) which module denied the request
2) the reason the request gets denied

In this way, sysadmins can immediately understand the causes and take
actions (if necessary).

Any advice or feedback on this proposal is highly welcomed (that's the
whole purpose of this email)!

Specially, I want to understand whether this is something worth doing
(besides scratching my own itch)? Is there any concerns, or did I miss any
important things? Let me know!

Thanks a lot!
Tianyin