We can consider making HeaderGroup public in 2.1.
Ideally we could add this without changing the interface.
Jandalf.
Michael Becke wrote:
There has not been any more discussion about this since my last response. Does anyone else have comments? If not, Jeff please let me know how you want me to proceed on this.
Thanks,
Mike
On Tuesday, February 4, 2003, at 08:53 AM, Michael Becke wrote:
- no need for fully qualified class names in @see or @link comments - please use @since 2.0beta1 new methods/classesCan do.- don't see a need for getFirstHeader and getLastHeader
I didn't think so at first either. For some uses though I think it works. For example if you want to get the content length from the headers you only want to read one value. Ideally there should only be only one value but we've seen cases where this is not true. These methods allow you to choose a particular header based upon how you value duplicates.
- getCondensedHeader, if there is one header, it returns a refrence to an internal datastructure, if more than one, it returns a copy. Its an optimization, somehow I'm torn about it
I hear you. This can be easily changed.Can we do this with zero changes to the HttpMethod interface? The users do not need access to the HeaderGroup; it'd be nice if it was package access rather than public.. They can always use the Header[] form, which is more general to them anyway. Its only internally that a HeaderGroup object is required. ... Not sure how to mitigate that with that interface.
It certainly could be. It would be nice to not have HttpMethod interface changes. I think hiding HeaderGroup significantly reduces its value though. The existing header methods are a little lacking. For example setHeader and removeHeader don't really work when multiple headers with the same name are allowed. The other problem is that there is no good way to get all of the header values with a particular name other than iterating over an array and comparing names.
I'm happy to remove these methods to HttpMethod if necessary. I would just like to make sure we really don't want these changes.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
