FTP open questions

2009-07-13 Thread William A. Rowe, Jr.
Just finished the last showstopper. I would be happy to advance this to release / general availability vote with the next release, if we can determine just a few oddball issue resolutions. Jim and I have already gone ahead and moved many internal interfaces out of the private headers, which was m

Re: mod_deflate DoS using HEAD

2009-07-13 Thread William A. Rowe, Jr.
William A. Rowe, Jr. wrote: > > * do not do server-side deflation (it is expensive). Whoops - forgot one more * do not do content deflation, only transfer deflation, which should not metered by the content-length, right?

Re: mod_deflate DoS using HEAD

2009-07-13 Thread William A. Rowe, Jr.
Nick Kew wrote: > Eric Covener wrote: > >> /* For a 304 response, only change the headers */ >> -if (r->status == HTTP_NOT_MODIFIED) { >> +if (r->status == HTTP_NOT_MODIFIED || r->header_only) { > > Technically speaking, screws up the protocol. > > IMHO it would be accep

Re: mod_deflate DoS using HEAD

2009-07-13 Thread Nick Kew
Eric Covener wrote: /* For a 304 response, only change the headers */ -if (r->status == HTTP_NOT_MODIFIED) { +if (r->status == HTTP_NOT_MODIFIED || r->header_only) { Technically speaking, screws up the protocol. IMHO it would be acceptable provided: (a) it's an opti

AuthBasicProvider failover and mod_authnz_ldap

2009-07-13 Thread Eric Covener
PR#47521 points out that when mod_authnz_ldap has some fatal LDAP connectivity error, it doesn't allow other AuthBasicProviders to have a shot at checking the userid. It seems like the normal use case for two providers is when there are two disjoint user repositories, and we only move on to search