On Mon, 2004-06-07 at 16:15, Brian W. Fitzpatrick wrote:
On Jun 7, 2004, at 8:45 AM, Bill Stoddard wrote:
Brian W. Fitzpatrick wrote:
On Jun 6, 2004, at 10:42 PM, Geoffrey Young wrote:
FYI, Fitz did a conversion of apache-1.3, which is now located at
Sumeet Singh wrote:
I would think that mod_proxy should make an independant decision (based
on compliance with the RFC, mod_proxy's configuration, type of origin
server etc) on whether it should send a chunked or dechunked request
body. For example, if the client sent chunked data that was
I had sent private Email to your @apache.org address
(since that's the one you use to provide HTTPD related
patches).
On Jun 8, 2004, at 5:10 PM, Rasmus Lerdorf wrote:
Uh, I never received anything on this. Did you actually send me
something? I'll have a look at addressing this issue. Releasing
Jean-Jacques Clar wrote:
I think there is a little typo with the submitted patch:
yes, of course :(
thanks for the fix
At 10:18 PM 6/8/2004, Rici Lake wrote:
The patch is now posted to bugzilla as [Bug 29450]. I believe that
conforms to the patches.html document cited below. Although that
document says -C3 is acceptable, I have submitted it in the
preferential -u format (which I also prefer, actually).
It says
Fair enough. I guess I am being sensitive here, because the
last time I submitted a patch to some other project, I did
it with -u and got told that I should use -c. :)
Anyway, I apologise for being grumpy and look forward to comments
on the patch itself.
On 9-Jun-04, at 8:29 AM, Greg Marr wrote:
Don't see that anywhere. Either eaten by spam filters or a gerbil.
Anyway, I don't understand why this would have broken mod_dav. If mod_dav
wants a keepalive connection it should determine this prior to the ap_die
and set conn-keepalive to 1. Or am I missing something with respect to
what
On Wed, Jun 09, 2004 at 09:21:07AM -0700, Rasmus Lerdorf wrote:
Don't see that anywhere. Either eaten by spam filters or a gerbil.
Anyway, I don't understand why this would have broken mod_dav. If mod_dav
wants a keepalive connection it should determine this prior to the ap_die
and set
On Wed, 9 Jun 2004, Joe Orton wrote:
On Wed, Jun 09, 2004 at 09:21:07AM -0700, Rasmus Lerdorf wrote:
Don't see that anywhere. Either eaten by spam filters or a gerbil.
Anyway, I don't understand why this would have broken mod_dav. If mod_dav
wants a keepalive connection it should
On Wed, Jun 09, 2004 at 11:04:23AM -0700, Rasmus Lerdorf wrote:
On Wed, 9 Jun 2004, Joe Orton wrote:
On Wed, Jun 09, 2004 at 09:21:07AM -0700, Rasmus Lerdorf wrote:
Don't see that anywhere. Either eaten by spam filters or a gerbil.
Anyway, I don't understand why this would have
On Wed, 9 Jun 2004, Joe Orton wrote:
When ap_die() is called, ap_set_keepalive() has not been called, and
r-connection-keepalive is set to 0, as it was initialized so.
The last thing ap_die does is call ap_send_error_response, which calls
ap_send_http_header, which calls ap_set_keepalive,
On Jun 9, 2004, at 3:24 PM, Rasmus Lerdorf wrote:
I guess what we are agreeing on here is that the logic that sets
keepalive
to 0 is faulty and that is probably where the real fix lies.
yeah... it's pretty inconsistent. Looking at ap_set_keepalive
even after we know the connection will be
Title: Does anyone know how to statically link libssl.a vs libssl.so.x
Hello,
I am trying to statically link libssl.a instead of libssl.so.x.
After doing a buildconf, configure and make; then ldd httpd on the final executable to look at the shared library dependencies and libssl.so.x id
Running ProxyPass with mod_deflate results in
an extraneous 20 bytes being tacked onto 304
responses from the backend.
The problem is that mod_deflate doesn't handle
the zero byte body, adds the gzip header and
tries to compress 0 bytes.
This patch detects the fact that there was no
data to
On Wed, 9 Jun 2004, Allan Edwards wrote:
+}
+else {
+/* this was a zero length response, remove gzip header bucket then
pass down the EOS */
+APR_BUCKET_REMOVE(APR_BRIGADE_FIRST(ctx-bb));
+APR_BUCKET_REMOVE(e);
+
On Wed, Jun 09, 2004 at 04:04:45PM -0500, Avery, Ken wrote:
Hello,
I am trying to statically link libssl.a instead of libssl.so.x.
After doing a buildconf, configure and make; then ldd httpd on the
final executable to look at the shared library dependencies and
libssl.so.x id there. I
But if you are allocating memory for cache entries that are
constantly expiring and being purged, the pool will continue to grow
until the server is restarted. The pool would end up with stale memory
that the system has no way of reclaiming outside of restarting the
server. NetWare doesn't
William,
Dagone spam filtering, this patch never made it to the
list. Well I'll send it again, from a different e-mail..
So, here's the patch that fixes it for Netscape/Mozilla,
and whatever other browsers work similarly.
John Wojtowicz
Senior Secure Systems Engineer
Trusted Computer
John wrote:
Dagone spam filtering, this patch never made it to the
list. Well I'll send it again, from a different e-mail..
So, here's the patch that fixes it for Netscape/Mozilla,
and whatever other browsers work similarly.
--- proxy_ftp.c 2004-05-28 15:15:15.960934000 -0400
+++ proxy_ftp.c.new
Brad Nicholes wrote:
But if you are allocating memory for cache entries that are
constantly expiring and being purged, the pool will continue to grow
until the server is restarted. The pool would end up with stale memory
that the system has no way of reclaiming outside of restarting the
Cliff Woolley wrote:
I haven't looked at the entire context of this, but if you remove a bucket
(brigade_first(ctx-bb) from a brigade without deleting it and without
having any extra pointers to it, you'll leak memory.
Thanks for catching that! I'll replace APR_BUCKET_REMOVE with
a call to
I guess that is a possibility but I still don't understand what the
problem is with using calloc() and free() for the ldap caching code.
This seems to be a common thing to do when global memory needs to be
allocated and deallocated constantly. To avoid having the memory grow
uncontrolably,
On Wed, 9 Jun 2004, Allan Edwards wrote:
Also just realized I need to add a call to deflateEnd().
Oh right, that too. :-)
e is on the brigade passed into deflate_out_filter and the gzip
header bucket is in ctx-bb so that is not a problem.
Ah, yeah, that would make sense. Cool.
hi all
I wanted to ping everyone about an idea I've been throwing around for a few
months now. I'd like the ability to shuffle the declared hook ordering
around, most likely during the post-config phase.
basically what I would like to be able to do is shift a hook from one place
(say,
On Wed, 9 Jun 2004, Geoffrey Young wrote:
I wanted to ping everyone about an idea I've been throwing around for a few
months now. I'd like the ability to shuffle the declared hook ordering
around, most likely during the post-config phase.
There was some discussion about this or something at
Cliff Woolley wrote:
On Wed, 9 Jun 2004, Geoffrey Young wrote:
I wanted to ping everyone about an idea I've been throwing around for a few
months now. I'd like the ability to shuffle the declared hook ordering
around, most likely during the post-config phase.
There was some discussion
APACHE 1.3 STATUS: -*-text-*-
Last modified at [$Date: 2004/05/20 15:16:42 $]
Release:
1.3.32-dev: In development
1.3.31: Tagged May 7, 2004. Announced May 11, 2004.
1.3.30: Tagged April 9, 2004. Not released.
1.3.29: Tagged October 24,
APACHE 2.0 STATUS: -*-text-*-
Last modified at [$Date: 2004/06/09 22:32:49 $]
Release:
2.0.50 : in development
2.0.49 : released March 19, 2004 as GA.
2.0.48 : released October 29, 2003 as GA.
2.0.47 : released July 09, 2003 as GA.
APACHE 2.1 STATUS: -*-text-*-
Last modified at [$Date: 2004/04/27 22:09:17 $]
Release [NOTE that only Alpha/Beta releases occur in 2.1 development]:
2.1.0 : in development
Please consult the following STATUS files for information
on related
Your document is attached.
--- Trend GateLock [EMAIL PROTECTED] (higp5.gatelock.com.tw)
** your_picture.pif
Trend GateLock [EMAIL PROTECTED] (higp5.gatelock.com.tw)
** your_picture.pif WORM_NETSKY.D
30 matches
Mail list logo
