Re: [PATCH]: mod_cache: don't store headers that will never be used

2007-07-30 Thread Sander Striker
On 7/31/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: > Niklas Edmundsson wrote: > > On Mon, 30 Jul 2007, Niklas Edmundsson wrote: > > > >> However, if stuff is really depending on Date/Expires being what it > >> thinks it is (*shiver*) then I guess there won't be any other options... > > > >

Re: [PATCH]: mod_cache: don't store headers that will never be used

2007-07-30 Thread William A. Rowe, Jr.
Niklas Edmundsson wrote: > On Mon, 30 Jul 2007, Niklas Edmundsson wrote: > >> However, if stuff is really depending on Date/Expires being what it >> thinks it is (*shiver*) then I guess there won't be any other options... > > Here's a version with a config directive, defaults to disabled. Silly

Re: svn commit: r560937 - /httpd/httpd/trunk/modules/filters/mod_deflate.c

2007-07-30 Thread William A. Rowe, Jr.
[EMAIL PROTECTED] wrote: > } > -else if (ap_strchr_c(encoding, ':') != NULL) { > +else if (ap_strchr_c(encoding, ',') != NULL) { Uhm - so blowing away q val logic? Actually, that doesn't look like a semi, that looks like a colon which has no meaning I can thin

Re: Strange segmentation fault

2007-07-30 Thread Nick Kew
On Mon, 30 Jul 2007 18:04:27 +0200 "[EMAIL PROTECTED]"<[EMAIL PROTECTED]> wrote: > I isolated my problem. > It seems that sometimes during xmlFreeDoc(doc) I get a Segmentation > fault. xmlFreeDoc is a function of libxml2 which I use inside my > module. I suppose that libxml2 uses malloc/free to al

Re: svn commit: r560386 - /httpd/httpd/branches/2.2.x/STATUS

2007-07-30 Thread Paul J. Reder
Okay, there is a 2.2.x branch version of the nested groups patch at http://people.apache.org/~rederpj/NestedGroups_2.2.xBranch.diff Nick Kew wrote: On Sat, 28 Jul 2007 10:58:27 -0400 "Paul J. Reder" <[EMAIL PROTECTED]> wrote: I'm quite certain that it applies since I developed the code on 2.2

Re: Strange segmentation fault

2007-07-30 Thread [EMAIL PROTECTED]
I found that a similar problem was this: http://mail-archives.apache.org/mod_mbox/httpd-modules-dev/200703.mbox/[EMAIL PROTECTED] So it seems that it's possibile. I don't understand how to solve it. Could you give me some hints? Best regards Marco > Sorry I don't understand the reply. > You ar

Apache bench - ssl sesion reuse and nagle issues

2007-07-30 Thread Kashyap Ashwin
Hello, I am benchmarking a JSON RPC server application that uses apache, mod_python, and mod_ssl. I noticed that ab (Apache Bench) does not do SSL session reuse. So I have implemented this feature as a patch to ab.c that I have copied at the end. One other issue is that Nagle algorithm really will

Re: [PATCH]: mod_cache: don't store headers that will never be used

2007-07-30 Thread Niklas Edmundsson
On Mon, 30 Jul 2007, Niklas Edmundsson wrote: However, if stuff is really depending on Date/Expires being what it thinks it is (*shiver*) then I guess there won't be any other options... Here's a version with a config directive, defaults to disabled. Thoughts? /Nikke -- -=-=-=-=-=-=-=-=-=-=

Re: Strange segmentation fault

2007-07-30 Thread Ralf Mattes
On Mon, 2007-07-30 at 16:14 +0200, [EMAIL PROTECTED] wrote: > I discovered some segmentation faults in apache error log. > So I wanted to understand the reason of these errors. > I put these statements in my module: > > ap_log_perror(APLOG_MARK, APLOG_ERR, 0, r->pool, "0:[%ld] %s", > (long)getpid(

Re: Strange segmentation fault

2007-07-30 Thread Mike
On 7/30/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Could you give me a hint to solve my problem? 1st of all: compile apache, apr and apu with -ggdb flag enabled; enable coredumps in apache config and analyze them with gdb. it always works. Kind regards.

Strange segmentation fault

2007-07-30 Thread [EMAIL PROTECTED]
I discovered some segmentation faults in apache error log. So I wanted to understand the reason of these errors. I put these statements in my module: ap_log_perror(APLOG_MARK, APLOG_ERR, 0, r->pool, "0:[%ld] %s", (long)getpid()); and ap_log_perror(APLOG_MARK, APLOG_ERR, 0, r->pool, "1:[%ld] %s",

Re: svn commit: r559837 - /httpd/httpd/trunk/modules/filters/mod_filter.c

2007-07-30 Thread Jim Jagielski
On Jul 26, 2007, at 3:46 PM, Ruediger Pluem wrote: This is correct (because provider->match is a union and provider- >match.string and provider->match.regex are the same thing), but confusing. I would prefer checking provider->match.regex instead. Seems to me that avoiding unions altoge

Re: Completely transform a request

2007-07-30 Thread Arturo 'Buanzo' Busleiman
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 [EMAIL PROTECTED] wrote: > That's all good news. You're almost there. In case you want to take a look, you can check out the filter function from http://www.buanzo.com.ar/files/openpgp.conn.filter.in.c > You have the 'content' encryption/decryptio

Re: svn commit: r560689 - in /httpd/httpd/trunk: CHANGES modules/filters/mod_deflate.c

2007-07-30 Thread André Malo
* Joe Orton wrote: > On Sun, Jul 29, 2007 at 01:37:20PM +0200, Ruediger Pluem wrote: > > And BTW, as the order of the encodings in Content-Encoding must be the > > order in which they have been applied, don't we need to ensure that > > gzip needs to be at the *end* of the content encoding string

Re: svn commit: r560689 - in /httpd/httpd/trunk: CHANGES modules/filters/mod_deflate.c

2007-07-30 Thread Joe Orton
On Sun, Jul 29, 2007 at 01:37:20PM +0200, Ruediger Pluem wrote: > And BTW, as the order of the encodings in Content-Encoding must be the > order in which they have been applied, don't we need to ensure that > gzip needs to be at the *end* of the content encoding string, as we > have to decode th

Re: Completely transform a request

2007-07-30 Thread TOKILEY
> Arturo wrote... > > Thanks for taking the time to discuss this with me. > I really appreciate it. > > I was able to read a whole "pgp-encrypted" request, > even a large 12+MB one using my code. I read the > content-length header, then read up to that quantity of > bytes, saving the brigades to

Re: [PATCH]: mod_cache: don't store headers that will never be used

2007-07-30 Thread Niklas Edmundsson
On Sun, 29 Jul 2007, Roy T. Fielding wrote: The solution is to NOT rewrite the on-disk headers when the following conditions are true: - The body is NOT stale (ie. HTTP_NOT_MODIFIED when revalidating) - The on-disk header hasn't expired. - The request has max-age=0 This is perfectly OK with RF

Re: [PATCH]: mod_cache: don't store headers that will never be used

2007-07-30 Thread Graham Leggett
On Mon, July 30, 2007 10:40 am, Niklas Edmundsson wrote: >> What may make this workable is the combination of "The body is NOT >> stale" >> with "max-age=0". The danger of not writing the headers is that an >> entity, >> once stale, will not be freshened when the spec says it should, and will >> c

Re: [PATCH]: mod_cache: don't store headers that will never be used

2007-07-30 Thread Niklas Edmundsson
On Sun, 29 Jul 2007, Graham Leggett wrote: What may make this workable is the combination of "The body is NOT stale" with "max-age=0". The danger of not writing the headers is that an entity, once stale, will not be freshened when the spec says it should, and will cause a thundering herd of co