Re: tux-list Digest, Vol 29, Issue 7

[email protected] wrote:

>i've released the tux3-2.6.18-1 Tux patch:
>
>   http://redhat.com/~mingo/TUX-patches/tux3-2.6.18-1
>
>this is a merge to v2.6.18, plus a few lockdep related fixes, and 64-bit 
>compiler warning eliminations.
>  
>
I was reading through this patch to catch up and saw a couple of things 
that look strange to me:

Index: linux/include/linux/errno.h
===================================================================
--- linux.orig/include/linux/errno.h
+++ linux/include/linux/errno.h
@@ -24,6 +24,9 @@
 #define EIOCBQUEUED	529	/* iocb queued, will get completion event */
 #define EIOCBRETRY	530	/* iocb queued, will trigger a retry */
 
+/* Defined for TUX async IO */
+#define EWOULDBLOCKIO	530	/* Would block due to block-IO */
+
 #endif
 
 #endif


Shouldn't EWOULDBLOCKIO have a unique value assigned to it?  In this 
case it's the same error code as EIOCBRETRY...

Later, when setting up the environment for a CGI call-out, I saw this:

+	WRITE_ENV("GATEWAY_INTERFACE=CGI/1.1");
+	WRITE_ENV("CONTENT_LENGTH=%d", req->post_data_len);
+	WRITE_ENV("REMOTE_ADDR=%d.%d.%d.%d", NIPQUAD(host));
+	WRITE_ENV("SERVER_PORT=%d", 80);
+	WRITE_ENV("SERVER_SOFTWARE=TUX/2.0 (Linux)");


Isn't the SERVER_PORT that tux listens to configurable?  A hard-coded 80 
here just seems wrong.  The code gets the "host" IP address from the 
socket "inet_sk(req->sock->sk)->daddr", so I'm guessing the port should 
come from there as well?

Another poster asked if "large" cookies could trigger a failover to 
Apache.  I see in the code that the limit on header size defaults to 
3000, but can be set with a sysctl

+unsigned int tux_max_header_len = 3000;


+	{	NET_TUX_MAX_HEADER_LEN,
+		"max_header_len",
+		&tux_max_header_len,
+		sizeof(int),
+		0644,
+		NULL,
+		proc_dointvec,
+		&sysctl_intvec,
+		NULL,
+		NULL,
+		NULL
+	},


The sysctl file would be /proc/sys/net/tux/max_header_len 

Just wondering,
Phil P.