Bug 23037 - RFE: HTTP 1.1 Install Support [Was: HTTP Installation Fails]
RFE: HTTP 1.1 Install Support [Was: HTTP Installation Fails]
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Erik Troan
Brock Organ
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-12-30 18:49 EST by Thornton Prime
Modified: 2007-04-18 12:30 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-04-15 20:17:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Thornton Prime 2000-12-30 18:49:53 EST
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 18:22:34 EST
Assigning to a developer.
Comment 2 Erik Troan 2001-01-08 14:42:14 EST
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 16:11:18 EST
This defect is considered MUST-FIX for Florence Gold release
Comment 4 Thornton Prime 2001-01-13 00:26:57 EST
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 '10.2.5.10' (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 http://10.2.5.10/7.1/RedHat/base/netstg1.img 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 http://10.2.5.10/7.1/RedHat/base/netstg1.img | md5sum
c0897ef501b24d6433dfa08323d6c541  -

The webserver log reports:
10.2.5.1 - - [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 12:33:50 EST
PCMCIA was foobar'd in this beta -- is fixed internally
Comment 6 Thornton Prime 2001-01-16 14:46:14 EST
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 14:52:29 EST
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 12:58:54 EST
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 < 10.15.10.29.32768 > poe.corp.jalan.com.http: . 1:1(0) ack
1 win 5840 <nop,nop,timestamp 3292 41793270> (DF)
08:54:12.364219 eth0 < 10.15.10.29.32768 > 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 > 10.15.10.29.32768: . 1:1(0) ack
46 win 5792 <nop,nop,timestamp 41793270 3292> (DF)
08:54:12.364596 eth0 > poe.corp.jalan.com.http > 10.15.10.29.32768: P 1:484(483)
ack 46 win 5792 <nop,nop,timestamp 41793270 3292> (DF)
08:54:12.364623 eth0 > poe.corp.jalan.com.http > 10.15.10.29.32768: F 484:484(0)
ack 46 win 5792 <nop,nop,timestamp 41793270 3292> (DF)
08:54:12.366483 eth0 < 10.15.10.29.32768 > poe.corp.jalan.com.http: . 46:46(0)
ack 484 win 6432 <nop,nop,timestamp 3292 41793270> (DF)
08:54:12.367520 eth0 < 10.15.10.29.32768 > poe.corp.jalan.com.http: R 46:46(0)
ack 484 win 6432 <nop,nop,timestamp 3292 41793270> (DF)
08:54:12.368005 eth0 < 10.15.10.29.32768 > poe.corp.jalan.com.http: R
972839868:972839868(0) win 0 (DF)



$ telnet poe.corp.jalan.com 80
Trying 64.22.132.134...
Connected to poe.corp.jalan.com (64.22.132.134).
Escape character is '^]'.
HEAD / HTTP/0.9

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 13:05:50 EST
Very likely -- could you try w/ apache?
Comment 10 Thornton Prime 2001-01-17 13:13:20 EST
See my last note. It works fine with Apache.
Comment 11 Erik Troan 2001-01-17 13:15:11 EST
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 13:27:27 EST
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 13:31:34 EST
True, but we use python's http support, and we get what we get...
Comment 14 Erik Troan 2001-01-17 16:30:11 EST
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-15 20:17:02 EDT
*** Bug 34931 has been marked as a duplicate of this bug. ***
Comment 16 Erik Troan 2001-06-28 16:34:56 EDT
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.