Re: debugging a timeout issue

2008-05-09 Thread Dirk-Willem van Gulik
On May 9, 2008, at 6:23 AM, Graham Dumpleton wrote: 2008/5/9 Sam Carleton [EMAIL PROTECTED]: I am a one man ISV that is using an Apache and an Apache Module. I am trying to trouble shoot a timeout issue that I cannot see, my customer is reporting the problem and he can consistently

Re: debugging a timeout issue

2008-05-09 Thread Sam Carleton
On Fri, May 9, 2008 at 12:23 AM, Graham Dumpleton [EMAIL PROTECTED] wrote: Since you see one request but not the second, one thing I would perhaps suggest doing is turn off KeepAlive and see if that makes a difference with the client. I am wondering, I do not see the timeout bug but my

Re: debugging a timeout issue

2008-05-09 Thread Joe Lewis
Sam Carleton wrote: On Fri, May 9, 2008 at 12:23 AM, Graham Dumpleton [EMAIL PROTECTED] wrote: Since you see one request but not the second, one thing I would perhaps suggest doing is turn off KeepAlive and see if that makes a difference with the client. I am wondering, I do not see

Looking for reviewers for the second edition of the Apache Pocket Reference

2008-05-09 Thread Andrew Ford
I am nearly finished with the technical review draft of the second edition of the Apache Pocket Reference (my deadline for this is 30 May), and am looking for a number of people to review the manuscript. I would be very grateful for any volunteers and I believe that there will be some free copies

Re: jumbo patch from 39380 - and moving things 'up' to mod_cache itself

2008-05-09 Thread Akins, Brian
What if Vary were much more than just HTTP Vary? It would be nice if the framework could support the external vary (ie, normal HTTP Vary) as well as any internal Vary. To use general mod_disk_cache structure, we currently have something sorta like this for vary metafiles: int cache_version

Re: svn commit: r654752 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS modules/generators/mod_cgid.c

2008-05-09 Thread Jeff Trawick
On Fri, May 9, 2008 at 6:57 AM, [EMAIL PROTECTED] wrote: Author: trawick Date: Fri May 9 03:57:46 2008 New Revision: 654752 URL: http://svn.apache.org/viewvc?rev=654752view=rev Log: backport from trunk: *) mod_cgid: Explicitly set permissions of the socket (ScriptSock) shared by

Re: mod_mbox compile issue on SuSE Enterprise 10

2008-05-09 Thread Jeff Trawick
On Thu, May 8, 2008 at 5:13 PM, Gregory Boyce [EMAIL PROTECTED] wrote: Ok, I found the trigger for the bug, but I'm not sure what the correct fix is. It appears that Apache on SuSE sets AP_DEBUG as part of the EXTRA_CPPFLAGS variable in config_vars.mk while Debian does not. Manually removing

Re: Looking for reviewers for the second edition of the Apache Pocket Reference

2008-05-09 Thread Nick Gearls
I'm interested Regards, Nick

Re: Looking for reviewers for the second edition of the Apache Pocket Reference

2008-05-09 Thread Albert Lash
Me too! On Fri, May 9, 2008 at 8:41 AM, Nick Gearls [EMAIL PROTECTED] wrote: I'm interested Regards, Nick -- My Blogs: http://www.docunext.com/ http://www.albertlash.com/

Re: Looking for reviewers for the second edition of the Apache Pocket Reference

2008-05-09 Thread Iñigo Medina García
Good idea! :-) Iim insterested too. Iñigo I am nearly finished with the technical review draft of the second edition of the Apache Pocket Reference (my deadline for this is 30 May), and am looking for a number of people to review the manuscript. I would be very grateful for any

Re: svn commit: r654752 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS modules/generators/mod_cgid.c

2008-05-09 Thread Joshua Slive
On Fri, May 9, 2008 at 8:27 AM, Jeff Trawick [EMAIL PROTECTED] wrote: On Fri, May 9, 2008 at 6:57 AM, [EMAIL PROTECTED] wrote: Author: trawick Date: Fri May 9 03:57:46 2008 New Revision: 654752 URL: http://svn.apache.org/viewvc?rev=654752view=rev Log: backport from trunk: *) mod_cgid:

Re: svn commit: r654752 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS modules/generators/mod_cgid.c

2008-05-09 Thread Jeff Trawick
On Fri, May 9, 2008 at 9:26 AM, Joshua Slive [EMAIL PROTECTED] wrote: Just put it in people.apache.org:/www/www.apache.org/dist/httpd/patches/apply_to_2.2.8/. The archive.apache.org/dist/ directory is an automatic copy of the stuff under www.apache.org/dist/. Thanks!

Re: svn commit: r654797 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS docs/manual/mod/mod_headers.xml modules/metadata/mod_headers.c

2008-05-09 Thread Chris Darroch
Jim Jagielski wrote: Add in r568323 and 568879. The approved patch lacked updates to the doccos and so really shouldn't have been approved as is, but what the heck, so I went ahead and pulled the doccos changes from the orig commit anyway. Also, since this is a userland change, it should really

Re: svn commit: r654797 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS docs/manual/mod/mod_headers.xml modules/metadata/mod_headers.c

2008-05-09 Thread Jim Jagielski
On May 9, 2008, at 1:18 PM, Chris Darroch wrote: Jim Jagielski wrote: Add in r568323 and 568879. The approved patch lacked updates to the doccos and so really shouldn't have been approved as is, but what the heck, so I went ahead and pulled the doccos changes from the orig commit anyway.

Re: jumbo patch from 39380 - and moving things 'up' to mod_cache itself

2008-05-09 Thread Graham Leggett
Dirk-Willem van Gulik wrote: There is a lot of valuable stuff in your jumbo patch - but I am not sure what the best approach is to fold it in. Could you have have a look at the rough patch I posted earlier today - and let me know if you have any thoughts as to which parts should be moved

Re: jumbo patch from 39380 - and moving things 'up' to mod_cache itself

2008-05-09 Thread Niklas Edmundsson
On Fri, 9 May 2008, Graham Leggett wrote: There is a lot of valuable stuff in your jumbo patch - but I am not sure what the best approach is to fold it in. Could you have have a look at the rough patch I posted earlier today - and let me know if you have any thoughts as to which parts should

Re: svn commit: r654805 [1/2] - in /httpd/httpd/branches/2.2.x/docs/manual: ./ developer/ faq/ howto/ misc/ mod/ platform/ programs/ rewrite/ ssl/ vhosts/

2008-05-09 Thread André Malo
* [EMAIL PROTECTED] wrote: Author: jim Date: Fri May 9 06:35:27 2008 New Revision: 654805 URL: http://svn.apache.org/viewvc?rev=654805view=rev Log: Update doccos Please update your build system checkout. Yours seems outdated ;) nd -- Winnetous Erbe:

Re: svn commit: r647263 - in /httpd/httpd/trunk: ./ docs/manual/mod/ include/ modules/aaa/ modules/filters/ modules/http/ server/

2008-05-09 Thread Graham Leggett
Ruediger Pluem wrote: Why is this needed? Should this job be performed by the ap_keep_body_filter that should be in our input filter chain if we want to keep the body? Of course this depends when we call ap_parse_request_form. If we call it during the authn/z phase the filter chain hasn't

Re: jumbo patch from 39380 - and moving things 'up' to mod_cache itself

2008-05-09 Thread Graham Leggett
Niklas Edmundsson wrote: I'm not convinced that forking the disk cache having two similar ones tuned for different usecases is a good idea in the long run, I'm pretty sure that the parts that needs tweaking can be solved with config options and documentation. For a development sprint like

Re: svn commit: r654968 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c server/protocol.c

2008-05-09 Thread Roy T. Fielding
On May 9, 2008, at 3:40 PM, [EMAIL PROTECTED] wrote: Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_http.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/ mod_proxy_http.c?rev=654968r1=654967r2=654968view=diff

Re: svn commit: r654968 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c server/protocol.c

2008-05-09 Thread Graham Leggett
Roy T. Fielding wrote: Please tell me that the chunk above is a mistaken commit. The chunk above is a mistaken commit. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature

Re: jumbo patch from 39380 - and moving things 'up' to mod_cache itself

2008-05-09 Thread Graham Leggett
William A. Rowe, Jr. wrote: I think the bigger idea that mod_cache must handle all rfc related issues is key. mem and disk cache should never have had substantial differences in behavior, but they do. So the more we can consolidate in mod_cache w.r.t. the requests themselves, the less the