Re: thoughts on ETags and mod_dav

2007-11-19 Thread Paritosh Shah
. Later we can make ap_meets_conditions_2() the default ap_meets_conditions(). -Paritosh. p.s. This approach was proposed by Paul Querna when I had a little chat with him at apachecon. On 10/25/07, Paritosh Shah [EMAIL PROTECTED] wrote: I had another look at ap_meets_conditions(), I guess what you

Re: thoughts on ETags and mod_dav

2007-10-25 Thread Paritosh Shah
On 10/20/07, Chris Darroch [EMAIL PROTECTED] wrote: Paritosh Shah wrote: Thanks for the patches ... I'll take a look when I get some time. I used resource-exists as the key instead of NON_EXTANT_RESOURCE or NO_RESOURCE as suggested by Chris Darroch, to avoid double negatives. I

Re: thoughts on ETags and mod_dav

2007-10-25 Thread Paritosh Shah
I had another look at ap_meets_conditions(), I guess what you say is true. The current ap_meets_conditions() *does* assume resource exists ( although it does not explicitly state that ). And in that case NO_RESOURCE would indeed be more appropriate. - Paritosh. On 10/25/07, Chris Darroch [EMAIL

Re: thoughts on ETags and mod_dav

2007-10-19 Thread Paritosh Shah
-hooks-set_headers() before calling ap_meets_conditions() Again, the patches are against 2.2.6 and I've tested them against mod_dav_fs w/ DEBUG_GET_HANDLER set to 1. Suggestions ? Comments ? - Paritosh Shah. On 10/18/07, Chris Darroch [EMAIL PROTECTED] wrote: Nick Kew wrote: My vote goes

Re: thoughts on ETags and mod_dav

2007-10-11 Thread Paritosh Shah
the weak etag bug ( sleep for a couple of seconds between consecutive requests ) - Paritosh. On 10/11/07, Chris Darroch [EMAIL PROTECTED] wrote: Hi -- A couple of months ago a short thread started in relation to the PRs #16593 and #38034 (which also references #42987) on the various problems

Re: 'prepared statement already exists' bug with postgres mod_authn_dbd

2007-04-11 Thread Paritosh Shah
Is this a persistent connections problem ? Or a postgres driver issue ? Has anyone been able to use mod_authn_dbd with postgres 8.2 ? thanks, Paritosh On 4/9/07, Paritosh Shah [EMAIL PROTECTED] wrote: I am getting a 'prepared statement authn_dbd_2 already exists' error while trying to use

'prepared statement already exists' bug with postgres mod_authn_dbd

2007-04-09 Thread Paritosh Shah
I am getting a 'prepared statement authn_dbd_2 already exists' error while trying to use mod_authn_dbd with postgres ( works fine with mysql ). PostgreSQL 8.2 log: LOG: connection received: host=127.0.0.1 port=38660 LOG: connection authorized: user=root database= ERROR: prepared statement

Re: mod_authn_dbd problem: prepared statements broken

2006-10-23 Thread paritosh
On Sunday 22 October 2006 08:12, Graham Leggett wrote: Graham Leggett wrote: Graham Leggett wrote: Some digging in the debugger shows that the value of dbd-prepared, the structure in which prepared statements are being kept, has the value 0x0001. Digging some more, it seems that

Re: apache 2.2 crashes at the start time in mod_dbd.c then preparing AuthDBDUserPWQuery

2006-08-18 Thread paritosh
)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1212180800 (LWP 23469)] apr_hashfunc_default (char_key=0x0, klen=0xbfc96c38) at tables/apr_hash.c:228 /home/paritosh/limespot/apache2.2/srclib/apr/tables/apr_hash.c:228:7055:beg:0xb7daa3ce (gdb) bt #0 apr_hashfunc_default

Re: apache 2.2 crashes at the start time in mod_dbd.c then preparing AuthDBDUserPWQuery

2006-08-18 Thread paritosh
On Fri, 2006-08-18 at 10:23 +0100, Nick Kew wrote: On Friday 18 August 2006 08:19, paritosh wrote: Hi Nick, I'm using the latest revision of mod_dbd.c and I still get a segfault on startup. My setup: CONFIGURE FLAGS: ./configure --enable-so --enable-auth-digest --enable-dbd

Re[2]: apache 2.2 crashes at the start time in mod_dbd.c then preparing AuthDBDUserPWQuery

2006-08-17 Thread paritosh
Hi all, I had a working installation of apache 2.2.2 with mod_dbd and mod_authn_dbd configured. Recently I upgraded to 2.2.3 and the server crashes with the same backtrace. ( it crashes in apr_hashfunc_default at tables/apr_hash.c:228 ). Have there been any developments towards resolving this ?