Bug 56790

Summary: ks=http kickstarts cause anaconda tracebacks with http 1.1 server
Product: [Retired] Red Hat Linux Reporter: John Berninger <johnw>
Component: anacondaAssignee: Jeremy Katz <katzj>
Status: CLOSED RAWHIDE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2CC: hanksdc, katzj, tao
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-04-16 01:44:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
kickstart config as retrieved through links
none
kickstart config as saved by anaconda installer
none
patch that makes an HTTP/1.0 request instead of HTTP/1.1 none

Description John Berninger 2001-11-27 19:34:18 UTC
Description of Problem:
The anaconda loader isues an HTTP/1.1 request for an http provided
kickstart, yet the loader cannot understand HTTP/1.1 responses.  Under
certain circumstances (i.e. scripted db-backended kickstarts) this causes
grbage characters to appear in the ks.cfg file, which causes tracebacks in
anaconda.

Version-Release number of selected component (if applicable):
7.2-7

How Reproducible:
always

Steps to Reproduce:
1. use PHP or Python to produce dynamic kickstart file through Apache
1.3.19 web server
2. attempt to ks=http from that script
3. anaconda complains about a KeyError

Actual Results:
(see attachments)

Expected Results:
normal install

Additional Information:
see attachments

Comment 1 John Berninger 2001-11-27 19:35:27 UTC
Created attachment 38804 [details]
kickstart config as retrieved through links

Comment 2 John Berninger 2001-11-27 19:36:31 UTC
Created attachment 38805 [details]
kickstart config as saved by anaconda installer

Comment 3 John Berninger 2001-11-27 19:37:22 UTC
Created attachment 38806 [details]
patch that makes an HTTP/1.0 request instead of HTTP/1.1

Comment 4 Jeremy Katz 2001-11-29 01:27:08 UTC
Hmm... but then we break with some HTTP server (though I don't remember which).
 Erik, do you have any opinions on this?

Comment 5 Daniel Hanks 2001-12-18 18:39:24 UTC
I'm getting almost exactly the same results as johnw 
reported. Same anaconda version, same apache version. I use Perl on apache-
3.1.19 (a RH7.1 box) to generate the kickstart file, and pull it over with ks=http...

Comment 6 Michael Fulbright 2002-01-16 20:14:20 UTC
I have a testbed where I pull ks files from an apache server (with a python CGI
backend) and have not seen this problem. How do we setup a machine to reproduce
this issue?

Comment 7 John Berninger 2002-01-16 20:42:41 UTC
I used a stock RHL 7.1 install (with updates) with the Apache, PHP, and MySQL
packages installed (all either stock 7.1 or 7.1 updates from Red Hat).  If
necessary, I can bundle the scripts I'm using into a tarball and attach it to
this bug, but the scripts are very simple.

Comment 8 Daniel Hanks 2002-01-17 23:28:04 UTC
What I found to be the problem, is that Apache (running my CGI) sends back a

Transfer-Encoding: 
chunked

header, as part of the response (since anaconda told the server it could speak HTTP 
1.1). So, Apache will then send back a number, which the HTTP 1.1 client should read as a number of 
bytes to read. The client then reads this number of bytes, and then one more line, which contains 
the next number of bytes to read, and so on until the document is completely served (This is all 
probably in an rfc somewhere...)

From what I can see, Anaconda just slurps back what Apache 
sends without regards to the transfer-encoding and puts it in place as the kickstart document. 
The mysterious numbers/characters that are showing up in the kickstart files are these 
transfer numbers indicating how many bytes are supposed to be read next.

From what I can see in 
the Anaconda code, no measures are taken to interpret this style of encoding, so the real 
solution would be to make sure if Anaconda says it can speak HTTP 1.1, it should mean it :-).

The 
patch given previously to change HTTP/1.1 to HTTP/1.0 works for me, but the real change should 
probably be to make Anaconda HTTP/1.1 compliant. Hopefully my description above will help in 
that effort.

Comment 9 Jeremy Katz 2002-04-01 22:45:26 UTC
Switched back to using HTTP/1.0 in CVS

Comment 10 Michael Fulbright 2002-04-16 01:44:37 UTC
Verified.