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.
Jandalf.
------- Additional Comments From [EMAIL PROTECTED] 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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
