Bug 99292 - tux 301 redirect location header incorrect when site has www subdomain
tux 301 redirect location header incorrect when site has www subdomain
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
9
All Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-07-16 22:44 EDT by me
Modified: 2007-04-18 12:55 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:41:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch of TUX to make redirects work properly (2.01 KB, patch)
2003-08-21 06:48 EDT, me
no flags Details | Diff

  None (edit)
Description me 2003-07-16 22:44:22 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
tux 301 redirect location header incorrect when site has www subdomain

example:
NOTE: /test is a directory, in /test there is a file called index.html


request:

GET /test HTTP/1.1
Host: www.test.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
Accept-Language: en-us, en;q=0.50
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.test.com/


response:

HTTP/1.1 301 Moved Permanently
Location: http://test.com.au/test/
Content-Length: 36
Connection: Keep-Alive
Content-Type: text/html

<HTML> 301 Moved Permanently </HTML>



remark:
I was expecting "Location: http://www.test.com.au/test/"

as having "Location: http://test.com.au/test/"
makes the assumption that both the www and the @ record point to the same
location (not only that but it also causes another lookup), infact why is it
doing a 301 error in the first place?
anyway.



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

How reproducible:
Always

Steps to Reproduce:
1.have tux running as a virtual server
2. have a www.test.com domain pointing configured on the virtual server
3. make a subdirectory on that www.test.com domain say test
4. have mozilla goto http://www.test.com/test
5. tux will attempt to redirect the location to http://test.com/test/ instead of
http://www.test.com/test/
6. done.
    

Actual Results:  HTTP/1.1 301 Moved Permanently
Location: http://test.com.au/test/
Content-Length: 36
Connection: Keep-Alive
Content-Type: text/html

<HTML> 301 Moved Permanently </HTML>

Expected Results:  HTTP/1.1 301 Moved Permanently
Location: http://www.test.com.au/test/
Content-Length: 36
Connection: Keep-Alive
Content-Type: text/html

<HTML> 301 Moved Permanently </HTML>

Additional info:

cat /etc/sysctl.tux
# tux sysctl configuration options not in /etc/sysconfig/tux
# please read http://www.redhat.com/docs/manuals/tux/TUX-2.2-Manual/

# logging 0 If set to 1, logging is enabled. If set to 0, logging is disabled.
net.tux.logging = 1
# virtual_server 0 (off) Turns on mass virtual hosting. This way any number of
hosts can be served by a single Red Hat Content Accelerator server without any
performance penalty at all. Refer to the Section called Mass Virtual Hosting for
details.
net.tux.virtual_server = 1

net.tux.http_subdocroot = www/html/
net.tux.ftp_subdocroot = ftp/pub/



cat /etc/sysctl.tux
# /etc/sysconfig/tux

# TUXTHREADS sets the number of kernel threads (and associated daemon
# threads) that will be used.  $TUXTHREADS defaults to the number of
# CPUs on the system.
TUXTHREADS=4

# DOCROOT is the document root; it works the same way as other web
# servers such as apache.  /var/www/html/ is the default.
DOCROOT=/var/

# LOGFILE is the file where tux logs information for each
# request. Note that tux writes log files in a binary format and to
# read them you will need to first convert them into standard
# W3C-conforming HTTPD log files using the utility tux2w3c. If no
# LOGFILE is specified then requests will not be logged.
LOGFILE=/var/log/tux

# DAEMON_UID and DAEMON_GID are the user and group as which the daemon runs
# They default to "nobody"
# This does not mean that you should execute untrusted modules -- they
# are opened as user/group root, which means that the _init() function,
# if it exists, is run as root.  This feature is only designed to help
# protect from programming mistakes; it is NOT really a security mechanism.
# DAEMON_UID=nobody
# DAEMON_GID=nobody

# CGIs can be started in a chroot environment by default.
# Defaults to $DOCROOT; set CGIROOT=/ if you want CGI programs
# to have access to the whole system.
# CGIROOT=/var/www/html

# each HTTP connection has an individual timer that makes sure
# no connection hangs forever. (due to browser bugs or DoS attacks.)
MAX_KEEPALIVE_TIMEOUT=600

# TUXMODULES is a list of user-space TUX modules.  User-space TUX
# modules are used to serve dynamically-generated data via tux.
# "man 2 tux" for more information
# TUXMODULES="demo.tux demo2.tux demo3.tux demo4.tux"

# MODULEPATH is the path to user-space TUXapi modules
# MODULEPATH="/"
Comment 1 me 2003-08-21 06:48:22 EDT
Created attachment 93814 [details]
Patch of TUX to make redirects work properly

This fixes the redirecting to domain name with striped www record.
Its a patch of the redhat kernel-source-2.4.20-19.9.i386.rpm
mingo
Comment 2 me 2003-08-21 06:50:27 EDT
Before you ask, yes i have tested the patch.
Comment 3 Bugzilla owner 2004-09-30 11:41:18 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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