hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <be...@u.washington.edu>
Subject Re: DO NOT REPLY [Bug 11218] - handle multivalue headers correctly
Date Tue, 04 Feb 2003 13:53:25 GMT
> - 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


Mime
View raw message