Re: java.net/170: HTTP client code treats headers as body

[Bryce McKinlay <bryce at albatross dot co dot nz>]

The following reply was made to PR java.net/170; it has been noted by GNATS.

From: Bryce McKinlay <bryce@albatross.co.nz>
To: John Stracke <francis@ecal.com>, java-gnats@sourceware.cygnus.com
Cc:  
Subject: Re: java.net/170: HTTP client code treats headers as body
Date: Fri, 10 Mar 2000 16:09:52 +1300

 John Stracke wrote:
 
 > Bryce McKinlay wrote:
 >
 > > Actually, the second part of the 170 patch is wrong, I think. The http status
 > > line is what is returned by getHeaderField(0), so it shouldn't be skipped.
 >
 > But it's not a header.  Hmm...ah, here we are: the status line is accessible
 > through methods of java.net.HttpURLConnection: getResponseCode() and
 > getResponseMessage()...though there's no method to get the protocol version.
 
 Sure, its not *really* a header, but if you call getResponseField(0) on the JDK
 1.2.2, you'll get back the status line. We usually try to copy the JDK's behaviour
 in these situations, even if it isnt formally specified in the API documentation.
 
 >  gcj doesn't currently implement getResponseCode() or getResponseMessage().  I'll write them tonight or
 > tomorrow.
 >
 
 Cool. A couple of points: 1. Its probibly best to work on the latest version of
 libgcj (I noticed your patches said 2.95.1 on them). There have been some changes
 to the URLConnection stuff since 2.95.1, and using cvs makes generating patches a
 lot easier anyway.  2. Significant changes require a copyrite assignment to be
 filled out (see http://sourceware.cygnus.com/java/contrib.html ). Best to contact
 Tom Tromey or Anthony Green about this as the procedure will be changing given the
 FSF/classpath merger.
 
 regards
 
   [ bryce ]