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.
My thought was that people creating specific instances of HttpMethod
like PostMethod would be able to access the HeaderGroups. I still
would like to have the header groups available for subclasses though.
How would you feel about making these methods protected?
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.
Can do.
The factoring out of the readLine details looks good. HeaderParser
should go into the util/ subpackage.
Sounds good. I'll make these changes and resubmit.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
