Bug 142627 - Tux doesn't redirect properly to directory when trailing slash is omitted
Tux doesn't redirect properly to directory when trailing slash is omitted
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: tux (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ingo Molnar
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-12-10 20:00 EST by Stefan Micke
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-19 15:11:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Stefan Micke 2004-12-10 20:00:19 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.7.5)
Gecko/20041108 Firefox/1.0

Description of problem:
Under normal circumstances, a query for a directory that has the
trailing slash missing should auto-ad that slash and still redirect to
that directory (this time with the slash appended), where it looks for
an index file.

Tux seems to have that general ability, however with virtual hosts
enabled, that function breaks. The problem is best explained by
including the server headers for the sample query

#1 Server Response: http://www.creativitypool.com/files
HTTP Status Code: HTTP/1.1 301 Moved Permanently
Location: http://creativitypool/files/
Content-Length: 36
Connection: Keep-Alive
Content-Type: text/html
Redirect Target: http://creativitypool/files/

As you can see, the Redirect Target is an invalid URL. Tux adds the
slash alright, but instead of redirecting to the directory within the
proper domain (www.creativitypool.com) it uses the virtual domain
handle (creativitypool) as the URL base. Obviously, the lookup fails.

Please note that this problem is increased by the fact that I have
strip_host_tail set to "1". If I set it to "0" the user is redirected
from http://www.creativitypool.com/files to
http://creativitypool.com/files/ - this is obviously better, because
the request gets at least through, but the sudden disappearance of the
"www." part still gives it a buggy appearance. I am assuming that with
 mass_hosting_hash set to a value higher than 0, redirection would be
broken, too.

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

How reproducible:

Steps to Reproduce:
(see above)

Additional info:
Comment 1 RHEL Product and Program Management 2007-10-19 15:11:30 EDT
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

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