hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Dever <jsde...@sympatico.ca>
Subject handle multivalue headers correctly
Date Sun, 09 Feb 2003 05:16:12 GMT
Hi Mike,

I'm still 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 a 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.

The factoring out of the readLine details looks good.  HeaderParser 
should go into the util/ subpackage.


>------- 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

View raw message