Roy T. Fielding wrote:
I can certainly understand that :) Here is a new patch along those
lines.
+1, but you might want to reduce the severity on those error messages
if this is actually a common occurrence. After all, there is nothing
that the server can do about it, and the client won't
+1
At 9:42 AM -0500 1/16/03, Jeff Trawick wrote:
I can certainly understand that :) Here is a new patch along those lines.
Index: main/http_main.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_main.c,v
retrieving revision 1.599
Roy T. Fielding wrote:
if (setsockopt(s, IPPROTO_TCP, TCP_NODELAY, (char *) just_say_no,
sizeof(int)) 0) {
+char buf[128];
+
+if (sin_client) {
+ap_snprintf(buf, sizeof(buf),
+, client %pA probably dropped the
At 7:47 AM -0500 1/16/03, Jeff Trawick wrote:
Roy T. Fielding wrote:
Second,
change the ap_log_error to the variable args version rather than
using a temporary buffer and ap_snprintf.
I'm afraid you've lost me here. What function is there to use in
place of ap_log_error()? Somehow use
whoops, I sent this to the wrong place the first time
Original Message
Subject: Re: [1.3 PATCH] enhance some trace messages
Date: Thu, 16 Jan 2003 09:42:30 -0500
From: Jeff Trawick [EMAIL PROTECTED]
To: Jim Jagielski [EMAIL PROTECTED]
References: [EMAIL PROTECTED] [EMAIL
First, the NETWARE part has to be above your additions.
The reason I put the NETWARE part below the first new code was because
I assumed (perhaps incorrectly) that there was no way that Apache or
library functions it called were going to mess with the value returned
by WSAGetLastError(), but
I can certainly understand that :) Here is a new patch along those
lines.
+1, but you might want to reduce the severity on those error messages
if this is actually a common occurrence. After all, there is nothing
that the server can do about it, and the client won't be complaining,
though it
Roy T. Fielding wrote:
First, the NETWARE part has to be above your additions.
The reason I put the NETWARE part below the first new code was because
I assumed (perhaps incorrectly) that there was no way that Apache or
library functions it called were going to mess with the value returned
Periodically a customer^H^H^H^H^H^H^H^Huser will call in and ask what
the heck these messages are and why are we idiots who pass bad
parameters to syscalls...
[Thu Mar 21 10:04:08 2002] [error] (22)Invalid argument: getsockname
[Thu Mar 21 10:05:03 2002] [warn] (22)Invalid argument: setsockopt:
