Bug 73021 - persistent connection and vhosting leads to 404s
persistent connection and vhosting leads to 404s
Status: CLOSED CANTFIX
Product: Red Hat Linux
Classification: Retired
Component: tux (Show other bugs)
7.3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Ingo Molnar
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-08-29 20:16 EDT by kitchen_506
Modified: 2007-04-18 12:46 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-18 14:29:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description kitchen_506 2002-08-29 20:16:25 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; You trust this)

Description of problem:
I was setting up tux to handle the images for a modest web farm (6 boxen) and
noticed that once I overcame the proxy shenanigans described in
http://www.redhat.com/mailing-lists/tux-list/msg01905.html, it was mostly stable
and happy serving raw images.  

Then came the problem.  When persistent connections were turned on, it would
lose the virtual host parameter and look in presumably the same vhost that
served the original connection.  

eg: hit www.example.com, get an html file that makes references to numerous
images.example.com.  With persistent connections on, some of the images were
404'd, others ok. The ok ones varied per request. With persistent connections
off (thanks to the wonders of mozilla) 100% ok every time.

I tried tweaking several parameters and nothing seemed to change this.  I
upgraded from 2.2.5 to 2.2.7 via a handy rpm -tb and gave that a go.  No go. 
Same results.

(BTW, a CHANGELOG in tux would be most cool.)

I enabled kernel logging and after figuring out that 2.2.7 had multiple spots
you need to tweak (well, *I* needed to tweak two :-) it logged some amusing
stuff into /var/log/messages.  Errant stuff.

eg: multiple requests in the kernel log for the same image from the images
vhost, but obv different based on both browser behaviour and the tux2w3c log.  

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
/etc/sysconfig/tux
VIRTUAL_SERVER=1   # err...legacy config attempt...but ignored afaik
CLIENT_PORT=8080

/etc/sysctl.tux
net.tux.virtual_server=1
net.tux.mode_forbidden=73
net.tux.max_keepalives=0
net.tux.Dprintk=1
net.tux.TDprintk=1

multiple vhosts, one with a doc that makes multiple references to one of the
others via IMG


Actual Results:  with keepalive: multiple variant BOOMs per reload
without keepalive: 100% happy every time

Expected Results:  happy joy

Additional info:

a genericisized snippet of the kernel log, original browser is mozilla 1.0:

Aug 29 16:37:48 afu kernel: }, query:{<null>}, ver:{HTTP/1.1
Aug 29 16:37:48 afu kernel: Host: www.example.com
Aug 29 16:37:48 afu kernel: User-Agent: Mozilla/5.0 [blah blah blah]
st_data:{<NULL>}(0).
Aug 29 16:37:48 afu kernel: ... headers: {GET / HTTP/1.1
Aug 29 16:37:48 afu kernel: Host: www.example.com
Aug 29 16:37:48 afu kernel: User-Agent: Mozilla/5.0 [blah blah blah]
rv:1.0.0) Gecko/20020607
Aug 29 16:37:48 afu kernel: Accept: text/xml,[blah blah blah]
Aug 29 16:37:48 afu kernel: Accept-Language: en-us, en;q=0.50
Aug 29 16:37:48 afu kernel: Accept-Encoding: gzip, deflate, compress;q=0.9
Aug 29 16:37:48 afu kernel: Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Aug 29 16:37:48 afu kernel: Connection: close
Aug 29 16:37:48 afu kernel: Cache-Control: max-age=0
Aug 29 16:37:48 afu kernel: 
Aug 29 16:37:49 afu kernel: }, uri:{/v3/contact.gif HTTP/1.1
Aug 29 16:37:49 afu kernel: Host: images.example.com
Aug 29 16:37:49 afu kernel: User-Agent: Mozilla/5.0 [blah blah blah]
rv:1.0.0) Gecko/20020607
Aug 29 16:37:49 afu kernel: Accept: text/xml,[blah blah blah]
Aug 29 16:37:49 afu kernel: Accept-Language: en-us, en;q=0.50
Aug 29 16:37:49 afu kernel: Accept-Encoding: gzip, deflate, compress;q=0.9
Aug 29 16:37:49 afu kernel: Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Aug 29 16:37:49 afu kernel: Connection: close
Aug 29 16:37:49 afu kernel: Referer: http://www.example.com/
Aug 29 16:37:49 afu kernel: 
Aug 29 16:37:49 afu kernel: }, query:{<null>}, ver:{HTTP/1.1
Aug 29 16:37:49 afu kernel: Host: images.example.co... post_data:{<NULL>}(0).
Aug 29 16:37:49 afu kernel: ... headers: {GET /v3/contact.gif HTTP/1.1
Aug 29 16:37:49 afu kernel: Host: images.example.com
Aug 29 16:37:49 afu kernel: User-Agent: Mozilla/5.0 [blah blah blah]
rv:1.0.0) Gecko/20020607
Aug 29 16:37:49 afu kernel: Accept: text/xml,[blah blah blah]
Aug 29 16:37:49 afu kernel: Accept-Language: en-us, en;q=0.50
Aug 29 16:37:49 afu kernel: Accept-Encoding: gzip, deflate, compress;q=0.9
Aug 29 16:37:49 afu kernel: Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Aug 29 16:37:49 afu kernel: Connection: close
Aug 29 16:37:49 afu kernel: Referer: http://www.example.com/


errr.... that's from the *successful* transfer (note the Connection: close) but
STILL logged WRONG here.

But look at the (ip filtered/neutered) goodness from /var/log/tux

216.148.218.195 - - [29/Aug/2002:16:37:48 -0700] "GET example.com/example.css
HTTP/1.1" 304 0 "-" ""
216.148.218.195 - - [29/Aug/2002:16:37:48 -0700] "GET
images.example.com/v3/corporate.gif HTTP/1.1" 304 0 "-" ""
216.148.218.195 - - [29/Aug/2002:16:37:48 -0700] "GET
images.example.com/v3/corporate_on.gif HTTP/1.1" 304 0 "-" ""
216.148.218.195 - - [29/Aug/2002:16:37:48 -0700] "GET
images.example.com/v3/contact.gif HTTP/1.1" 404 0 "-" ""
216.148.218.195 - - [29/Aug/2002:16:37:48 -0700] "GET
images.example.com/v3/clear.gif HTTP/1.1" 200 49 "-" ""
216.148.218.195 - - [29/Aug/2002:16:37:48 -0700] "GET
images.example.com/v3/face.jpg HTTP/1.1" 200 6221 "-" ""
216.148.218.195 - - [29/Aug/2002:16:37:48 -0700] "GET
images.example.com/v3/whatcan.gif HTTP/1.1" 200 3268 "-" ""

notice how contact.gif is asked for but once, as would be expected.
Comment 1 Ingo Molnar 2003-07-05 04:08:59 EDT
Are you sure this isnt the result of a handoff of the connection to Apache?
Apache must also be able to serve the same content as Tux - because if a
non-accelerated request is passed down to Apache it stays there and it will
handle all subsequent requests from that persistent connection. If this is not
desired then persistent connections should be turned off in httpd.conf
("KeepAlive Off").
Comment 2 kitchen_506 2003-07-07 09:29:59 EDT
It's going to be a while before I can cycle to this again given workload and
plans and that the configurations supporting this were from almost a year
*discrete cough* ago.  I'm guessing mid August before I can get a meaningful
update in.

Initial knee jerk defense says I had everything right.  What am I saying?  OF
COURSE I had everything right, I'm a user in this situation.  :-)


Comment 3 Bill Nottingham 2006-10-18 14:29:13 EDT
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Red Hat apologizes that these issues have not been resolved yet. We do
want to make sure that no important bugs slip through the cracks.
If this issue is still present in a current Fedora Core release, please
open a new bug with the relevant information.

Closing as CANTFIX.

Note You need to log in before you can comment on or make changes to this bug.