You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@znep.com> on 1997/01/19 20:27:00 UTC
[PATCH] suggested fix for lingering stuff
I think that the below patch reflects what I would suggest doing to
fix up the lingering close stuff.
Untested, and we need someone with a SVR4 system (and a Unixware one
would be good... may also need to add USE_SHUTDOWN in the UW section
of conf.h) to do some testing and see if they can replicate the problem
with data being truncated (compiling without any of the three options)
and then see if USE_SHUTDOWN fixes it.
Comments?
Index: PORTING
===================================================================
RCS file: /home/marcs/archive/apache/cvs/apache/src/PORTING,v
retrieving revision 1.2
diff -c -r1.2 PORTING
*** PORTING 1996/12/17 23:19:15 1.2
--- PORTING 1997/01/19 19:20:58
***************
*** 205,210 ****
--- 205,225 ----
USE_LONGJMP:
use the longjmp() call instead of siglongjmp()
+ USE_LINGCLOSE:
+ Use Apache's soft "lingering close" feature to close
+ connections; designed to be a better behaved USE_SO_LINGER.
+ Causes problems on some platforms.
+
+ USE_SHUTDOWN:
+ Call shutdown() before close()ing a connection. Needed on
+ some broken (mainly SVR4) TCP stacks which don't send queued
+ data when a close() is done on a socket.
+
+ USE_SO_LINGER:
+ Set the SO_LINGER option on sockets. Possible alternative
+ to USE_LINGCLOSE, however some broken TCP stacks do not
+ implement a timeout, leaving hung connections around.
+
--
NO_*:
***************
*** 215,223 ****
NO_SETSID:
NO_USE_SIGACTION:
Do not use the sigaction() call, even if we have it.
! NO_LINGCLOSE:
! Do not use Apache's soft, "lingering" close feature to
! terminate connections.
--
MISC #DEFINES:
--- 230,236 ----
NO_SETSID:
NO_USE_SIGACTION:
Do not use the sigaction() call, even if we have it.
!
--
MISC #DEFINES:
Index: conf.h
===================================================================
RCS file: /home/marcs/archive/apache/cvs/apache/src/conf.h,v
retrieving revision 1.69
diff -c -r1.69 conf.h
*** conf.h 1997/01/10 13:23:31 1.69
--- conf.h 1997/01/19 19:13:37
***************
*** 285,291 ****
* to 0x2000000 which is still PLENTY of space. I doubt if
* even on heavy systems sbrk() would be called at all...
*/
- #define NO_LINGCLOSE
#elif defined(SVR4)
#define NO_KILLPG
--- 285,290 ----
***************
*** 298,303 ****
--- 297,303 ----
#define getwd(d) getcwd(d,MAX_STRING_LEN)
/* A lot of SVR4 systems need this */
#define USE_FCNTL_SERIALIZED_ACCEPT
+ #define USE_SHUTDOWN
#elif defined(UW)
#define NO_KILLPG
Index: http_main.c
===================================================================
RCS file: /home/marcs/archive/apache/cvs/apache/src/http_main.c,v
retrieving revision 1.106
diff -c -r1.106 http_main.c
*** http_main.c 1997/01/12 20:38:12 1.106
--- http_main.c 1997/01/19 19:15:17
***************
*** 309,315 ****
* before closing the connection.
*/
! #ifndef NO_LINGCLOSE
static void lingering_close (int sd, server_rec *server_conf)
{
int dummybuf[512];
--- 309,315 ----
* before closing the connection.
*/
! #ifdef USE_LINGCLOSE
static void lingering_close (int sd, server_rec *server_conf)
{
int dummybuf[512];
***************
*** 360,366 ****
shutdown (sd, 2);
close (sd);
}
! #endif
void usage(char *bin)
{
--- 360,366 ----
shutdown (sd, 2);
close (sd);
}
! #endif /* USE_LINGCLOSE */
void usage(char *bin)
{
***************
*** 1667,1680 ****
#endif
bflush(conn_io);
! #ifdef NO_LINGCLOSE
bclose(conn_io); /* just close it */
#else
if (r)
lingering_close (conn_io->fd, r->server);
else
close (conn_io->fd);
! #endif
}
}
--- 1667,1686 ----
#endif
bflush(conn_io);
! #ifndef USE_LINGCLOSE
! #ifdef USE_SHUTDOWN
! /* broken (mostly SVR4) TCP stacks discard queued data if a
! * close() is done before a shutdown().
! */
! shutdown(conn_io->fd, 2);
! #endif
bclose(conn_io); /* just close it */
#else
if (r)
lingering_close (conn_io->fd, r->server);
else
close (conn_io->fd);
! #endif
}
}
Re: [PATCH] suggested fix for lingering stuff
Posted by Dean Gaudet <dg...@arctic.org>.
+1
Dean