Red Hat Bugzilla – Bug 142627
Tux doesn't redirect properly to directory when trailing slash is omitted
Last modified: 2007-11-30 17:07:05 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 http://www.creativitypool.com/files #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): tux-3.2.19-2 How reproducible: Always Steps to Reproduce: (see above) Additional info:
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: http://www.redhat.com/security/updates/errata/ 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.