William McKee wrote:
On Thu, Jun 24, 2004 at 02:35:39PM -0400, William McKee wrote:
On Thu, Jun 24, 2004 at 09:30:29AM -0400, Geoffrey Young wrote:
please take the time to excercise the candidate through all your existing
applications that use Apache-Test and report back successes or failures.
William McKee wrote:
Hi,
Here's an interesting problem I've come across. I have an application
that is occassionally retrieving duplicate data from a BerkeleyDB. I've
written a couple tests which, so far, cannot duplicate the problem (one
using a direct database interface and another using A::T).
Commenting out lines 669 and 1696 make it work fine. I remember having
this discussion a few months back but did not find a solution.
Apparently it is still an issue.
Yup, but it was an issue with previous A-T releases as well, so it's not
a showstopper. Someone who can reproduce this
On Jun 25, 2004, at 8:23 AM, Geoffrey Young wrote:
nope. I think apache.org has been having email issues - my announce
came 3
hours later, and a bunch of messages were duplicated. or maybe it was
just me.
No, I'm on the road and just found out that the network I'm on has
sendmail stuff locked
David Wheeler wrote:
On Jun 25, 2004, at 8:31 AM, David Wheeler wrote:
blarg. a revised candidate is in the same place. sorry about that.
Thanks, I'll try it later today.
Works great for me! Only issue I'm seeing is that
Crequests_redirectable = 0 isn't working on one of my
On Jun 25, 2004, at 12:02 PM, Geoffrey Young wrote:
check the version of lwp - IIRC there was a behavior change in recent
versions.
You could be right. I have the latest, 5.79, on that box, and 5.76 on
my other boxes. Seems like it might make sense to fix that before
releasing 1.12. I'll look
On Jun 25, 2004, at 1:49 PM, David Wheeler wrote:
You could be right. I have the latest, 5.79, on that box, and 5.76 on
my other boxes. Seems like it might make sense to fix that before
releasing 1.12. I'll look at it later today if you don't beat me to
it. It'll be tomorrow at the soonest I
I recently patched bug 10722. My patch was against 2.0.49, for a Client
who needed it in a hurry.
I'm just porting it to 2.1-HEAD. In doing so, I find there's an existing
patch that saves and restores cookies without rewriting the Domain and
Path components. AFAICS my patch would/should
Hi,
I have an Apache2 server that streams video to a VLC
client. I have used NeTraMet to capture the traffic
and used this data to draw the traffic profile. There
is no other traffic on the test-bed (except for RIP).
This profile shows a peak of about 3MB at the very
beginning. After that, the
Don't you think,
that the client is filling up it's buffer, and the after it's full just
stream what it has played ?
André
aarboard ag
internet - networks - screenprint design - multimedia
Egliweg 10 - Postfach 214 - CH-2560 Nidau (Switzerland)
Phone +41 32 332 9714 - Fax +41 32 332 9715
When COMSPEC is unset or set to something bogus, trying to start Apache with a
piped logger configured results in the messages
ap_spawn_child: Bad file descriptor
Couldn't fork child for piped log process
The Bad file descriptor issue may indicate a problem in the cleanup logic,
but it hides
Nick Kew wrote:
I recently patched bug 10722. My patch was against 2.0.49, for a Client
who needed it in a hurry.
I'm just porting it to 2.1-HEAD. In doing so, I find there's an existing
patch that saves and restores cookies without rewriting the Domain and
Path components. AFAICS my
Hi André,
I had thought that, but I just wanted to be sue.
Do you know a reason why there is a 3MB peak at the
start? Is it something to do with Server set-up
connection requirements?
Rgds,
Jesse
--- Andre Schild [EMAIL PROTECTED] wrote:
Don't you think,
that the client is filling up it's
To replace the addrspace field that was added in the cgi_exec_info_t
struct in mod_cgi.h I will like to propose extending the use of the
detached (apr_int32_t) field in cgi_exec_info_t and apr_procattr_t
structs.
Currently that field is set to 0 by default and 1 if the process to be
Jesse Kielthy wrote:
Do you know a reason why there is a 3MB peak at the
start? Is it something to do with Server set-up
connection requirements?
The 3MB peak is probably caused by your test running over a fast network.
Apache will send as much data as your client is willing to receive, and
in
Jim Jagielski [EMAIL PROTECTED] writes:
Nick Kew wrote:
[...]
It appears just to merge Set-Cookie headers in r-err_headers_out with
those in r-headers_out. The latter have just come from the backend
(the server proxied). But how/why should there be (any) cookies in
r-err_headers_out
+1
Looks like an oversite that this patch wasn't applied long ago. The pattern of saving the errno of an earlier
operation then restoring it on error exit is repeated all over alloc.c.
Bill
eff Trawick wrote:
When COMSPEC is unset or set to something bogus, trying to start Apache
with a piped
On 25 Jun 2004, Joe Schaefer wrote:
Jim Jagielski [EMAIL PROTECTED] writes:
Nick Kew wrote:
[...]
It appears just to merge Set-Cookie headers in r-err_headers_out with
those in r-headers_out. The latter have just come from the backend
(the server proxied). But how/why should
Joe Schaefer wrote:
But is the err_headers_out logic in proxy_http.c HEAD really ok?
It appears to put a copy of r-err_headers_out into r-headers_out,
so I'm wondering why this doesn't produce duplicates in the final
response (ie. doesn't httpd add r-err_headers_out itself, in
Jim Jagielski [EMAIL PROTECTED] writes:
Joe Schaefer wrote:
But is the err_headers_out logic in proxy_http.c HEAD really ok?
It appears to put a copy of r-err_headers_out into r-headers_out,
so I'm wondering why this doesn't produce duplicates in the final
response (ie. doesn't httpd
Joe Schaefer wrote:
Just to be sure we're on the same page- you agree here that HEAD
will erroneously produce duplicates of any Set-Cookie headers
in the proxy server's r-err_headers_out table.
Sure looks like that :) It does not appear that err_headers_out
is cleared in the proxy logic
On Thu, Jun 24, 2004 at 05:13:45PM +0200, Sander Striker wrote:
From: Andre Schild [mailto:[EMAIL PROTECTED]
As there are no other problem reportts, it's time to tag RC3 ?
Correct.
Can you pull in the latest apr_file_info.h from the 0.9 branch when you
retag to pick up the
William A. Rowe, Jr. wrote:
Refer to http://www.apache.org/dev/apply-license.html --- especially;
To apply the ALv2 to a new software distribution, include one copy of
the license text by copying the file:
On Fri, 25 Jun 2004, Jim Jagielski wrote:
So the
apr_table_do(addit_dammit, save_table, r-err_headers_out,
Set-Cookie, NULL);
line should be removed.
OK, that's what I needed to know. I'll still have to modify my patch
slightly to work with
On Thu, 17 Jun 2004, Francois-Rene Rideau wrote:
[ message quoted in full and crossposted to [EMAIL PROTECTED] ]
I have experienced quite some trouble due to design bugs in ProxyPass,
and have proposed a patch for apache 1.3.
The very same bugs are present in apache 2.0, and a similar fix
25 matches
Mail list logo
