handle multivalue headers correctly

[Jeffrey Dever <js...@sympatico.ca>]

Hi Mike,

I'm concerned about having public methods in HttpMethodBase that
are not in the HttpMethod interface.  These two public interfaces should
not diverge.  I had this same problem in the past, where I added a
  public method to the abstract class, and not the interface.  Then I saw
user code that was casting from the nice interface to the abstract class
to access services that were not supposed to be accessed.

So I like the idea of a HeaderGroup, but don't like public additions to
the HttpMethodBase class.  So when I said that it would be desirable to
make no chages to the HttpMethod interface, that includes public changes
to HttpMethodBase.

One other note, we use the terminology "footers" as headers that can be
at the end of a chunked body.  The RFC terminology is really "trailers".
  While footers has been used for a while in HttpClient, and the term is
arbitrairy, we probablly should migrate to the RFC terminology if possible.

Jandalf.


 >------- Additional Comments From becke@u.washington.edu  2003-02-08 
23:18 -------
 >Attached previously is a second attempt at fixing this problem. 
Here's what's new:
 >
 > - HttpMethod no longer has any changes
 > - @since 2.0beta1 tags have been added
 > - absolute @see and @link tags been made relative
 > - a static HttpConnection.readLine(InputStream) method has been added 
and is
 >being used by HttpConnection and HeaderParser.
 > - HeaderGroup.getCondensedHeader() now always returns a new Header
 >
 >
 >