hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Dever <jsde...@sympatico.ca>
Subject Re: DO NOT REPLY [Bug 11218] - handle multivalue headers correctly
Date Sat, 08 Feb 2003 00:42:14 GMT
I've been thinking about it too.  I still feel that we should keep the 
HeaderGroup behind the scenes, and only expose Header[].  This will 
still solve the requirements of this feature, while protecting users 
from change.

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/classes
>>
>>
>> Can 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: 
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: 
> commons-httpclient-dev-help@jakarta.apache.org
>
>



Mime
View raw message