Bug 101265 - HTTP install adds extra leading / to some paths
Summary: HTTP install adds extra leading / to some paths
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux Beta
Classification: Retired
Component: anaconda   
(Show other bugs)
Version: beta1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Mike McLean
URL:
Whiteboard:
Keywords:
: 101522 123607 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-07-30 14:49 UTC by Mike Shaver
Modified: 2007-04-18 16:56 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-24 18:59:58 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Mike Shaver 2003-07-30 14:49:32 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030523

Description of problem:
When selecting HTTP install, and providing a site path of

/~jacob/severn/

the Red Hat installer will request some files (the first such file is the
hdlist) with the prefix

//~jacob/severn/

which doesn't go to the same place.  (I believe this to be a characteristic of
the matching that mod_userdir does to know that it's supposed to head over to
public_html.)

Version-Release number of selected component (if applicable):
Severn beta 1 installer.

How reproducible:
Always

Steps to Reproduce:
1. Set up an install under a userdir (~msw/public_html)
2. Select HTTP install
3. Wait for it to tell you that it can't load the header list
4. Inspect your HTTP logs to see the extra leading /
5. (Optional) add a RedirectMatch rule so that you can install anyway

Comment 1 Mike Shaver 2003-07-30 15:44:28 UTC
Severn beta1 bugs are supposed to be marked i386, I now recall.

Comment 2 Bill Nottingham 2003-08-05 03:32:47 UTC
*** Bug 101522 has been marked as a duplicate of this bug. ***

Comment 3 Michael Fulbright 2003-08-13 17:03:10 UTC
I think I have this fixed. Please try again in our next beta.

Comment 4 l0cksley 2004-06-25 16:42:41 UTC
*** Bug 123607 has been marked as a duplicate of this bug. ***

Comment 5 l0cksley 2004-06-25 18:16:40 UTC
I've downloaded anaconda-10.0-5.src.rpm and tried to trace
the logMessages.

In mountUrlImage() in loader2/urlinstall.c,
we start in the URL_STAGE_MAIN state
and call urlMainSetupPanel() in loader2/urls.c.
This function gets the URL from the user
and stores it in a (struct iurlinfo).
It also forces ui->prefix to have a leading slash.

Returning to mountUrlImage(),
we change to the URL_STAGE_FETCH state
and call loadUrlImages(), which calls
loadSingleUrlImage(), which calls
urlinstStartTransfer() in loader2/urls.c.
This function generates the "transferring http://..."
logMessage with the extra slash I see in virtual terminal 3.
The bad URL is then passed to httpGetFileDesc()
in loader2/ftp.c, which presumably fails.

There is a block near the end of mountUrlImage()
with the comment

"sanitize url so we dont have problems like bug #101265"
"basically avoid duplicate /'s"

but I think this bug occurs before it is reached.

Comment 6 Jeremy Katz 2006-04-24 18:59:58 UTC
Mass-closing lots of old bugs which are in MODIFIED (and thus presumed to be
fixed).  If any of these are still a problem, please reopen or file a new bug
against the release which they're occurring in so they can be properly tracked.


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