Bug 34931

Summary: HTTP network installs fail with FTP IO error
Product: [Retired] Red Hat Linux Reporter: David Morse <david_j_morse>
Component: installerAssignee: Erik Troan <ewt>
Status: CLOSED RAWHIDE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0CC: gaudet_roger, msw, tsombakos_mark
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-05-09 18:40:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
tcpdump of Apache and TUX GET requests during HTTP net install none

Description David Morse 2001-04-05 23:02:15 UTC
Attempting to install RH7 over a network *always* fails via HTTP, but 
works fine via FTP.  I've tried both TUX 2.0 and IIS 5.0 as Web servers, 
both fail the same way.

Using a browser, I can GET /path/RedHat/base/netstg1.img just fine, but I 
get an "FTP IO error" from the RH7 bootnet disk.

Let me stress that FTP works fine with the same IP address and path, so 
networking is not the problem.  The 3c59x driver is loaded and works 

Reproducible: Always
Steps to Reproduce:
1.  Create RH7 boot disk from bootnet.img on RH7 CD1
2.  Boot a machine with that floppy (Dell Precision 410 in my case)
3.  Choose HTTP network install, enter IP address and path of where files 
are on web server.

Actual Results:  Get a dialog box with the error "Failed to 
retrieve /RH7/RedHat/base/netstg1.img: FTP IO error"
Then a second dialog box with title "HTTP" and body "Unable to retrieve 
the first install image"

Expected Results:  The network images should have been downloaded (as the 
FTP network install does) and installation should have proceeded.

VC3 showed the 3c59x NIC was found, and I can ping this machine from the 
Web server.  VC3 also shows "transferring to a fd" for every failed 

I used a packet monitor on the network to determine that the GET request 
*does* come into the Web server, and it sends netstg1.img to the client 
without problems.  I have no idea why the installer is giving an FTP IO 
error message (esp since it's HTTP).

Comment 1 Brent Fox 2001-04-11 18:23:00 UTC
HTTP installs *do* work with Red Hat Linux 7.  Our QA dept. tests all of the
installation methods, although our HTTP servers are all Red Hat Linux running
Apache.  I don't think TUX or IIS has been tested as an HTTP installation
server.  Having said that, I'm not sure why it's not working for you.  Since the
GET request is reaching the web server, it looks like the server isn't
responding correctly to the request.  Have you tried pointing a different
machine at the web server and see if you can pull netstg1.img over via a web
browser.  That would take the installer completely out of the equation, so maybe
we can narrow the problem down a little.

Comment 2 David Morse 2001-04-11 23:56:56 UTC
> Have you tried pointing a different machine
> at the web server and see if you can pull
> netstg1.img over via a web browser.

Yes, in the original bug report above I said "Using a browser, I can 
GET /path/RedHat/base/netstg1.img just fine, but I get an "FTP IO error" from 
the RH7 bootnet disk."

I will attempt to install tomorrow with Red Hat/Apache and let you know what 

Comment 3 David Morse 2001-04-13 22:18:08 UTC
I just tested with Red Hat/Apache 1.3.19 (from RH 7.1) and it works great.  I 
just tested TUX 2.0 (also from RH 7.1) and it failed, although GETs with a 
browser again worked fine.

I'm going to attach a tarball that shows a tcpdump of the Apache case and the 
TUX case.  The Apache one is larger, obviously, since it successfully sends  

Comment 4 David Morse 2001-04-13 22:20:17 UTC
Created attachment 15347 [details]
tcpdump of Apache and TUX GET requests during HTTP net install

Comment 5 Brent Fox 2001-04-13 23:49:54 UTC
Hmm.  Thanks for your information.  This is an interesting problem.  I will look
at your tcpdump info when I have more time.  I wonder what is different about
the other web servers that makes things not work.  This very well could be an
installer problem.  I wonder if connecting to an Apache server running on a
Windows box would work...

Comment 6 Brent Fox 2001-04-16 00:17:06 UTC
Actually, this problem has been reported before.  Resolving as a duplicate.

*** This bug has been marked as a duplicate of 23037 ***

Comment 7 Mark Tsombakos 2001-05-04 21:24:08 UTC
The problem seems to be in Anaconda, file loader/ftp.c

Line 445 reads:
sprintf(buf, "GET %s \"HTTP/1.0\"\r\n\r\n", remotename);

This specifically includes quotes around HTTP/1.0.  IIS and
who knows what other web servers don't like this.  Apache seems
to ignore it.  I don't see the quotes in the HTTP spec at www.w3c.org, FWIW.

Comment 8 David Morse 2001-05-04 22:51:27 UTC
This problem still exists in Seawolf, so the problem is not with old Python 
libs, as Brent suggested.

Comment 9 Brock Organ 2001-05-07 12:49:30 UTC
Hi Brent,

Can we put the text of the solution of the other bug (23037) in this one also? 
The other bug is a non-public bug, so Mark (tsombakos_mark@emc.com) is unable 
to view it ... :)

Comment 10 Brent Fox 2001-05-07 19:40:27 UTC
Ok, we'll take another look at this one.

Comment 11 Brent Fox 2001-05-09 18:36:58 UTC
Here's an excerpt from the HTTP/1.1 spec (of course, we're using HTTP/1.0, so
things may differ)

 The absoluteURI form is REQUIRED when the request is being made to a
   proxy. The proxy is requested to forward the request or service it
   from a valid cache, and return the response. Note that the proxy MAY
   forward the request on to another proxy or directly to the server
   specified by the absoluteURI. In order to avoid request loops, a
   proxy MUST be able to recognize all of its server names, including
   any aliases, local variations, and the numeric IP address. An example
   Request-Line would be:

       GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

   To allow for transition to absoluteURIs in all requests in future
   versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
   form in requests, even though HTTP/1.1 clients will only generate
   them in requests to proxies.

   The authority form is only used by the CONNECT method (section 9.9).

   The most common form of Request-URI is that used to identify a
   resource on an origin server or gateway. In this case the absolute
   path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
   the Request-URI, and the network location of the URI (authority) MUST
   be transmitted in a Host header field. For example, a client wishing
   to retrieve the resource above directly from the origin server would
   create a TCP connection to port 80 of the host "www.w3.org" and send
   the lines:

       GET /pub/WWW/TheProject.html HTTP/1.1
       Host: www.w3.org

   followed by the remainder of the Request. Note that the absolute path
   cannot be empty; if none is present in the original URI, it MUST be
   given as "/" (the server root).

Comment 12 Brent Fox 2001-05-09 18:38:21 UTC
So, saying something like:
GET /index.html HTTP/1.1
Host: www.microsoft.com

works on IIS.  It also works on Apache, for what it's worth.  I don't know if it
works on TUX or not.

Comment 13 Mark Tsombakos 2001-05-09 18:40:40 UTC
Yes, but saying

GET /index.html "HTTP/1.1"  (quotes intended, and included from Anaconda source code)

does _not_ work on IIS.

Comment 14 Erik Troan 2001-06-28 20:33:14 UTC
We're doing this now in the loader:

sprintf(buf, "GET %s HTTP/1.1\t\nHost: %s\r\n\r\n", remotename, hostname);