Re: WebDAV and ACL (RFC3744), status?

2014-12-31 Thread Graham Leggett 
On 01 Feb 2012, at 5:53 PM, Brian J. France br...@brianfrance.com wrote:

 I had started breaking up the patches from mod_dav_acl into smaller chunks 
 and getting them imported into the trunk.
 
 My goal was to get a mod_dav_acl like module added.  I say like because 
 mod_dav_acl currently requires xfs and stores the auth information in the xfs 
 attributes and I wanted to create a more authn type module.  Something that 
 could have a flat file, dbm, dbd, etc type plugins.
 
 After mod_dav_acl was done I wanted to get mod_caldav and mod_cardav imported 
 as well, but free time dried up and I never finished.

Keen to revive this again.

I just tried to build mod_dav_acl against trunk, and after patching the 
function signatures for dav_error_new, I get the errors below.

There seem to be two key outstanding issues:

- dav_error needs to be extended to support childtags, not sure if a patch was 
submitted for this.

- 'dav_resource' has no member named ‘acl_hooks’ - I am not sure what change 
needs to be made to the mod_dav_acl code (if any) to support this?

[minfrin@Host-001 mod_dav_acl]$ make -k
make  all-recursive
make[1]: Entering directory `/home/minfrin/mod_dav_acl'
Making all in lib
make[2]: Entering directory `/home/minfrin/mod_dav_acl/lib'
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..
-I/usr/include/httpd -DLINUX -D_REENTRANT -D_GNU_SOURCE -pthread 
-I/usr/include/libxml2 -I/usr/include/apr-1-g -O2 -MT 
libdavacl_la-dav_acl.lo -MD -MP -MF .deps/libdavacl_la-dav_acl.Tpo -c -o 
libdavacl_la-dav_acl.lo `test -f 'dav_acl.c' || echo './'`dav_acl.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/httpd -DLINUX 
-D_REENTRANT -D_GNU_SOURCE -pthread -I/usr/include/libxml2 -I/usr/include/apr-1 
-g -O2 -MT libdavacl_la-dav_acl.lo -MD -MP -MF .deps/libdavacl_la-dav_acl.Tpo 
-c dav_acl.c  -fPIC -DPIC -o .libs/libdavacl_la-dav_acl.o
dav_acl.c: In function 'dav_acl_privilege_error':
dav_acl.c:80: error: 'dav_error' has no member named 'childtags'
dav_acl.c: In function 'dav_acl_exec_error':
dav_acl.c:106: error: 'dav_error' has no member named 'childtags'
dav_acl.c:106: error: 'dav_error' has no member named 'childtags'
dav_acl.c:106: error: 'dav_error' has no member named 'childtags'
dav_acl.c:106: error: 'dav_error' has no member named 'childtags'
dav_acl.c: In function 'dav_acl_store_owner':
dav_acl.c:1509: error: 'dav_resource' has no member named 'acl_hooks'
dav_acl.c:1510: error: expected '=', ',', ';', 'asm' or '__attribute__' before 
'*' token
dav_acl.c:1510: error: 'acl' undeclared (first use in this function)
dav_acl.c:1510: error: (Each undeclared identifier is reported only once
dav_acl.c:1510: error: for each function it appears in.)
dav_acl.c:1516: error: 'dav_resource' has no member named 'acl_hooks'
make[2]: *** [libdavacl_la-dav_acl.lo] Error 1
make[2]: Target `all' not remade because of errors.
make[2]: Leaving directory `/home/minfrin/mod_dav_acl/lib'
Making all in tools
make[2]: Entering directory `/home/minfrin/mod_dav_acl/tools'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/minfrin/mod_dav_acl/tools'
Making all in man
make[2]: Entering directory `/home/minfrin/mod_dav_acl/man'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/minfrin/mod_dav_acl/man'
make[2]: Entering directory `/home/minfrin/mod_dav_acl'
/bin/sh ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
-I/usr/include/httpd -DLINUX -D_REENTRANT -D_GNU_SOURCE -pthread 
-I/usr/include/libxml2 -I/usr/include/apr-1-g -O2 -MT 
mod_dav_acl_la-mod_dav_acl.lo -MD -MP -MF .deps/mod_dav_acl_la-mod_dav_acl.Tpo 
-c -o mod_dav_acl_la-mod_dav_acl.lo `test -f 'mod_dav_acl.c' || echo 
'./'`mod_dav_acl.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I/usr/include/httpd -DLINUX 
-D_REENTRANT -D_GNU_SOURCE -pthread -I/usr/include/libxml2 -I/usr/include/apr-1 
-g -O2 -MT mod_dav_acl_la-mod_dav_acl.lo -MD -MP -MF 
.deps/mod_dav_acl_la-mod_dav_acl.Tpo -c mod_dav_acl.c  -fPIC -DPIC -o 
.libs/mod_dav_acl_la-mod_dav_acl.o
mod_dav_acl.c:884: error: expected '=', ',', ';', 'asm' or '__attribute__' 
before 'acl'
mod_dav_acl.c:893: error: expected '=', ',', ';', 'asm' or '__attribute__' 
before '*' token
mod_dav_acl.c: In function 'send_principal_props':
mod_dav_acl.c:1000: error: 'dav_resource' has no member named 'acl_hooks'
mod_dav_acl.c: In function 'davacl_handler':
mod_dav_acl.c:1438: warning: assignment makes pointer from integer without a 
cast
mod_dav_acl.c: In function 'initialize_module':
mod_dav_acl.c:1529: error: 'acl' undeclared (first use in this function)
mod_dav_acl.c:1529: error: (Each undeclared identifier is reported only once
mod_dav_acl.c:1529: error: for each function it appears in.)
mod_dav_acl.c: At top level:
mod_dav_acl.c:1594: warning: excess elements in struct initializer
mod_dav_acl.c:1594: warning: (near initialization for 'res_hooks')
make[2]: *** [mod_dav_acl_la-mod_dav_acl.lo] Error 1
/bin/sh ./libtool

Re: [Patch] Simplifying mod_alias

2014-12-31 Thread Graham Leggett 
On 22 Dec 2014, at 2:24 PM, Eric Covener cove...@gmail.com wrote:

 You'll still have 7 directives though.  Some of them will be marked
 deprecated because they're less flexible. Sometimes less flexible is a
 sign of simplicity and not something to be relegated to a compat
 module.

The *Match directives (outside of the *Match containers) are definitely not 
simple - they all support regexes, but the scope of these regexes is limited to 
that single directive. This is confusing and suffers poor performance.

 You'll also have two modules and two pages in the manual. The examples
 for Redirect will now have configuration sections with named
 back-references and won't work in htaccess.

The FilesMatch container should support htaccess, and if there is a reason it 
doesn’t work that’s a bug that would be fixed.

 These users whose eyes bleed at the difference between Redirect and
 RedirectMatch or trying to capture the first component of the path
 aren't exactly going to do cartwheels when at the idea of new
 configuration sections and named back-references to accomplish a basic
 task.

I personally would be delighted with such a change.

The expression support inside require directives combined with this change have 
vastly simplified configurations that made my brain bleed in the past. Template 
based configuration is now possible where this was difficult before.

 I still don't see any reason to call the existing *Match deprecated to
 add expression support.

I see no link between the two. I would like to deprecate the *Match directives, 
but that has no bearing on expression support.

Regards,
Graham
—

Re: [Patch] Simplifying mod_alias

2014-12-31 Thread Eric Covener 
On Wed, Dec 31, 2014 at 8:57 AM, Graham Leggett minf...@sharp.fm wrote:
 You'll also have two modules and two pages in the manual. The examples
 for Redirect will now have configuration sections with named
 back-references and won't work in htaccess.

 The FilesMatch container should support htaccess, and if there is a reason it 
 doesn’t work that’s a bug that would be fixed.

I don't think FilesMatch is enough functionally, because you're too
limited in what you can check and match.

Re: [Patch] Simplifying mod_alias

2014-12-31 Thread Eric Covener 
On Wed, Dec 31, 2014 at 8:57 AM, Graham Leggett minf...@sharp.fm wrote:
 I still don't see any reason to call the existing *Match deprecated to
 add expression support.

 I see no link between the two. I would like to deprecate the *Match 
 directives, but that has no bearing on expression support.

I thought the entire point of the thread was that expression support
in the base directives obsoleted the *Match versions.  If you didn't
have the expression support, how would you describe the deprecation of
RedirectMatch to a user?  Should they use mod_rewrite?

Re: [Patch] Simplifying mod_alias

2014-12-31 Thread Graham Leggett 
On 31 Dec 2014, at 5:12 PM, Eric Covener cove...@gmail.com wrote:

 I don't think FilesMatch is enough functionally, because you're too
 limited in what you can check and match.

Can you clarify in more detail? If this is so, I am keen to fix it.

Regards,
Graham
—

Re: [Patch] Simplifying mod_alias

2014-12-31 Thread Eric Covener 
On Wed, Dec 31, 2014 at 10:30 AM, Graham Leggett minf...@sharp.fm wrote:
 I don't think FilesMatch is enough functionally, because you're too
 limited in what you can check and match.

 Can you clarify in more detail? If this is so, I am keen to fix it.

For a URL of http://example.com/foo/bar/baz.html

# this matches against baz.html only
FilesMatch (.*\.html)$
  Redirect http://other.example.com/$1
/FilesMatch

You would not have any way to match or capture some part of /foo/bar/.
  You could use the entire URL in an expression, but I think it would
be difficult to tease it apart, and even making it just conditional
would require something like wrapping in if.  I think there are some
big gaps in string-valued expressions, even if you do try to write a
sophisticated one (this has popped up for me in a handful of contexts
and I have flailed around in the grammar to no avail)