tux not handling content due to large cookies in header

[Morgan Demers]

Hi Everyone,

This is my first message on the list and I'd just like to introduce myself. My name is Morgan Demers and I run a fairly large network of sites. I rely quite heavily on tux for serving static content. I've just recently happened upon what I think to be a bug, but might be by design. I rely on cookies fairly heavily - for sessions, temporary storage of small sets of data, etc... I've just recently discovered that when a a browser sends a fairly large Cookie header for a domain that tux is serving static content for - tux will break and pass the request on to Apache even though the file exists and should be served. I've tested this out with large sets of cookies and then after clearing my cookies - and it seems to be that situation each time. I have virtual hosting on, and have multiple domains on the same server. Even in the tux log you can see a problem - typically when a request is made it has --domain.com--/--request path-- but when the headers are too large (due to all the cookies) the request looks like this /--request path--. Has anyone encountered this problem before? Is there a workaround other than having a seperate domain name for static content (such that no cookies are passed to the server)?

Some Debug Output from gettuxconfig:

Jun  8 11:22:17 picsfolio kernel: PRINT req d58e0000 <f8a569c0>, sock d00ebc34
Jun  8 11:22:17 picsfolio kernel: ... idx: 0
Jun  8 11:22:17 picsfolio kernel: ... sock d00ebc34, sk f301c880, sk->state: 1, sk->err: 0
Jun  8 11:22:17 picsfolio kernel: ... write_queue: 0, receive_queue: 1, error_queue: 0, keepalive: 1, status: 0
Jun  8 11:22:17 picsfolio kernel: ...tp->send_head: 00000000
Jun  8 11:22:17 picsfolio kernel: ...tp->snd_una: 20971c91
Jun  8 11:22:17 picsfolio kernel: ...tp->snd_nxt: 20971c91
Jun  8 11:22:17 picsfolio kernel: ...tp->packets_out: 00000000
Jun  8 11:22:17 picsfolio kernel: ... meth:{GET /ps/admin.jpg HTTP/1.1^M
Jun  8 11:22:17 picsfolio kernel: Accept: */*^M
Jun  8 11:22:17 picsfolio kernel: Accept-Language: en-us^M
Jun  8 11:22:17 picsfolio kernel: UA-CPU: x86^M
Jun  8 11:22:17 picsfolio kernel: Accept-Encoding: gzip, deflate^M
Jun  8 11:22:17 picsfolio kernel: If-Modified-Since: Wed, 07 Feb 2007 05:12:33 GMT^M
Jun  8 11:22:17 picsfolio kernel: If-None-Match: "2988fa-950-f956b240"^M
Jun  8 11:22:17 picsfolio kernel: User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; Alexa Toolbar; .NET CLR 2.0.50727)^M
Jun  8 11:22:17 picsfolio kernel: Host: p.#domain removed#.com^M
Jun  8 11:22:17 picsfolio kernel: Connection: Keep-Alive^M
Jun  8 11:22:17 picsfolio kernel: Cookie: ###############cookie data removed for security/privacy##################... post_data:{<NULL>}(0).
Jun  8 11:22:17 picsfolio kernel: ... headers: {<NULL>}

Here is how the request looks in the tux log:

#ip removed# - - [08/Jun/2007:11:22:26 -0400] "GET /ps/admin.jpg HTTP/1.1" -1 0 "-" ""

and here is how the request should have looked in the tux log:

#ip removed# - - [08/Jun/2007:11:23:19 -0400] "GET p.#domain removed#.com/ps/admin.jpg HTTP/1.1" 200 2384 "-" ""


------------

if you notice in the gettuxconfig log, it has "headers: {<NULL>}" meaning I think the large cookie data breaks the header processing mechanism in tux and that in turn forces tux to hand over the request to Apache?

Any help would be most appreciated,
Thanks in advance,
Morgan Demers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/tux-list/attachments/20070608/e85eb052/attachment.htm>