Bug 23037 - RFE: HTTP 1.1 Install Support [Was: HTTP Installation Fails]
Summary: RFE: HTTP 1.1 Install Support [Was: HTTP Installation Fails]
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Erik Troan
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2000-12-30 23:49 UTC by Thornton Prime
Modified: 2007-04-18 16:30 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2001-04-16 00:17:05 UTC

Attachments (Terms of Use)

Description Thornton Prime 2000-12-30 23:49:53 UTC
I was not able to install via HTTP. It returned an error that it couldn't
retrieve netstg1.img. The same directory worked for an FTP install (and the
file is plainly accessible to lynx or netscape or wget). The web server is
a thttpd server.

Comment 1 Michael Fulbright 2001-01-03 23:22:34 UTC
Assigning to a developer.

Comment 2 Erik Troan 2001-01-08 19:42:14 UTC
Can you check the web server logs to make sure that the install is looking for
the file you think it is?

Comment 3 Glen Foster 2001-01-11 21:11:18 UTC
This defect is considered MUST-FIX for Florence Gold release

Comment 4 Thornton Prime 2001-01-13 05:26:57 UTC
More info from a beta2 install ...

Using pcmcia (with the pcmcia.img + pcmciaadd.img) install or text mode
install (with the bootnet.img). The webserver is a thttpd server from 7.0
Powertools on a standard 7.0 install (with ext3 beta upgrades, not that
that would matter any).

Selected webserver '' (also tried by the hostname) path
'7.1' (also tried '/7.1/' and '7.1').

The webserver log records NO hit.

The install console reports:

  transferring to a fd

The install screen reports:

  failed to retrieve 7.1/RedHat/base/netstg1.img: Bad FTP server response.

(Note the 'FTP' even though I selected HTTP.)

The webserver can access the install client (verified with ping). The
install client can access the webserver (works fine in FTP mode).

The webserver works fine. From another station

$ lynx -source | md5sum
c0897ef501b24d6433dfa08323d6c541  -

The webserver log reports: - - [11/Jan/2001:14:04:19 -0800] "GET /7.1/RedHat/base/netstg1.img
HTTP/1.0" 200 1962770 "" "Lynx/2.8.4dev.7 libwww-FM/2.14"

From the server:

# md5sum 7.1/RedHat/base/netstg1.img 
c0897ef501b24d6433dfa08323d6c541  7.1/RedHat/base/netstg1.img

If I go back and select the identical options with FTP, it works. The
webserver root and the FTP server root are the same directory.

Maybe I'm missing something, but I just can't get it to work :(

Comment 5 Erik Troan 2001-01-16 17:33:50 UTC
PCMCIA was foobar'd in this beta -- is fixed internally

Comment 6 Thornton Prime 2001-01-16 19:46:14 UTC
Sorry if I wasn't clear, this happens with normal bootnet.img installs as well
as the PCMCIA installs, with the same error message.

The bootnet.img install was on a plain old Dell Desktop with an Intel eepro100.

Comment 7 Erik Troan 2001-01-16 19:52:29 UTC
Hmm, so much for the easy answer. Could you tcpdump that link to see what http
traffic is being generated?

Comment 8 Thornton Prime 2001-01-17 17:58:54 UTC
Here is a TCP dump, this time the server is a 7.1 machine running the 7.1
powertools thttpd. Again, nothing shows up in the thttpd logs. I'm guessing
thttpd doesn't like HTTP/0.9?

08:54:12.364048 eth0 < > poe.corp.jalan.com.http: . 1:1(0) ack
1 win 5840 <nop,nop,timestamp 3292 41793270> (DF)
08:54:12.364219 eth0 < > poe.corp.jalan.com.http: P 1:46(45)
ack 1 win 5840 <nop,nop,timestamp 3292 41793270> (DF)
08:54:12.364260 eth0 > poe.corp.jalan.com.http > . 1:1(0) ack
46 win 5792 <nop,nop,timestamp 41793270 3292> (DF)
08:54:12.364596 eth0 > poe.corp.jalan.com.http > P 1:484(483)
ack 46 win 5792 <nop,nop,timestamp 41793270 3292> (DF)
08:54:12.364623 eth0 > poe.corp.jalan.com.http > F 484:484(0)
ack 46 win 5792 <nop,nop,timestamp 41793270 3292> (DF)
08:54:12.366483 eth0 < > poe.corp.jalan.com.http: . 46:46(0)
ack 484 win 6432 <nop,nop,timestamp 3292 41793270> (DF)
08:54:12.367520 eth0 < > poe.corp.jalan.com.http: R 46:46(0)
ack 484 win 6432 <nop,nop,timestamp 3292 41793270> (DF)
08:54:12.368005 eth0 < > poe.corp.jalan.com.http: R
972839868:972839868(0) win 0 (DF)

$ telnet poe.corp.jalan.com 80
Connected to poe.corp.jalan.com (
Escape character is '^]'.

HTTP/0.9 400 Bad Request
Server: thttpd/2.16 29feb00
Content-type: text/html
Date: Wed, 17 Jan 2001 16:59:08 GMT
Last-modified: Wed, 17 Jan 2001 16:59:08 GMT
Accept-Ranges: bytes
Connection: close

I verified that it works fine with Apache, though. Why is anaconda using
HTTP/0.9? It would be best to support 1.1 to allow installs/upgrades off
name-based vhosts. Supporting 1.0 seems to be the easiest thing, but if this is
not possible it is probably worth reporting or documenting that the installer
requires Apache or another HTTP/0.9 compatible server.

Comment 9 Erik Troan 2001-01-17 18:05:50 UTC
Very likely -- could you try w/ apache?

Comment 10 Thornton Prime 2001-01-17 18:13:20 UTC
See my last note. It works fine with Apache.

Comment 11 Erik Troan 2001-01-17 18:15:11 UTC
Sorry, I didn't see that bit. This isn't an install bug, but a thttp one instead.

Comment 12 Thornton Prime 2001-01-17 18:27:27 UTC
It's not a thttpd bug because other web servers that don't support 0.9 (the
'ass-backwards version) won't work. Additionally, using 0.9 means that you can't
use named virtual host installs with any web server.

I've renamed this bug and re-opened it as a RFE. Upgrading at least to support
HTTP/1.0 should be trivial, though I'll admit that it is an enhancement and not
a bug, per se.

Comment 13 Erik Troan 2001-01-17 18:31:34 UTC
True, but we use python's http support, and we get what we get...

Comment 14 Erik Troan 2001-01-17 21:30:11 UTC
This was in the loader, actually.

I changed it to use HTTP 1.0 instead, which was straightforward. Making it use
1.1 would also be easy, but pointless because then then python would need
hacking. Should be done someday though.

Comment 15 Brent Fox 2001-04-16 00:17:02 UTC
*** Bug 34931 has been marked as a duplicate of this bug. ***

Comment 16 Erik Troan 2001-06-28 20:34:56 UTC
The loader is 1.1 now; the python probably isn't.

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