Response Header ordering

[Jeffrey Dever <js...@sympatico.ca>]

HeaderSet is not a good name, because a set implies "unordered". 
 Perhaps HeaderList, which could implement the List interface (but that 
might be a little fat).  Or just plain Headers with custom methods as 
you described.

Also might want a somthing like  "String toExternalForm(String name)" 
method that produces:
name1: value1
name1: value2, value3
name1: value4

And mabye even takes in a "boolean condensed" that would produce:
name1: value1, value2, value3, value4

The scope of what you are suggesting is reasonable.  Somthing like that 
needs to be done to address that bug which is marked for the 2.0 release 
anyway.

Jandalf.


Michael Becke wrote:

> I agree that Headers are everywhere any that some of their use is  
> questionable.  I think making a change to the Header class itself is  
> not a good idea since it is used ubiquitously and mostly works.  My  
> plan was to focus more on the collection of Headers.  As you say the  
> current HashMap storage is inadequate but efficient.  Though choice 
> of  algorithm is of little importance when working with such a small 
> data  set.  It seems to me that the best solution is one that uses a 
> custom  storage method(a new class) for the headers.  That way we can  
> enforce/control the functionality we wish to have for querying the  
> headers.  The new class might look something like this:
>
> HeaderSet {
>
>     // get's all headers in the order they were added
>     Header[] getAllHeaders()
>
>     // gets the headers for the given name, again in order
>     Header[] getHeaders(String name)
>
>     boolean containsHeader(String name)
>
> }
>
> The following changes would be made to HttpMethod:
>
> HttpMethod {
>
>     void setRequestHeaders(HeaderSet)
>
>     HeaderSet getResponseHeaderSet()
>
>     HeaderSet getRequestHeaderSet()
>
>     HeaderSet getResonseFooterSet()
>
>     // would be changed to call getHeaders(String) on the HeaderSet and
>     // combine multiple values with a ","
>     Header getResponseHeader(String)
>
> }
>
> The existing header methods in HttpMethod would be deprecated in  
> deference to the new HeaderSets.
>
> Doing it this way I think would successfully move the header storage 
> to  a new class but would allow for API compatibility.  As far as 
> wether or  not we need to make this change for 2.0 or 2.1, I'm not 
> sure.  We  should probably post the question to the list and see what 
> people  think.  I'm happy to do it now, but there are so many changes 
> in 2.0  already it may be difficult for users to catch up.
>
> Mike
>
>
> On Friday, January 31, 2003, at 01:54 AM, Jeffrey Dever wrote:
>
>> Well, at one point I was going to rewrite Header and NameValuePair,  
>> but the more I looked at the more scared I became.  8-E  (that was  
>> supposed to be a smiley of me wide eyed and gritting my teeth).  The  
>> interheritance hierachy has more classes in it, and some of the code  
>> is downright terrible.  I decided that I couldn't do it safely and 
>> let  it wait untill regexp came along.
>>
>> About header storage, I think that a compressed hashtable of a few  
>> entries is foolish: order is removed, the hashtable is fat and what  
>> you put in is not what you get out.  It makes httpclient poor for  
>> testing response headers and always casts some doubt when  
>> troubleshooting an application problem with the wirelog.
>> But the compression and the map interface sure does give convienent  
>> access to the headers.  I don't like the idea of a call to  
>> getHeader(String) and having to iterate through a list all the 
>> time.   I don't like getNumHeaders(String).  I don't like having to 
>> iterate  over a list to find a particular header name.  I can't think 
>> of an  ideal datastructure native in java.  Somone suggested a  
>> SequencedHashMap.  I dunno.  Maybe we need somthing custom.
>>
>> Do I think this warrents a new take on header storage?  Yes.  But  
>> Headers are *everywhere*, including the public interface, so there 
>> is  the potential to be quite disruptive.  I'm reconsidering wether 
>> if  this is a good idea to do in the 2.0 timeframe.  We could just 
>> write  it up as a known issue and tackle other, easier to solve 
>> problems and  revisit it early in 2.1
>>
>> What do you think?
>>
>> -jsd
>>
>>
>> Michael Becke wrote:
>>
>>> Hi Jeff,
>>>
>>> Yes, I was just looking through rfc2616 and noticed the part about   
>>> compressing headers into a single value.  Sure, it's an okay thing 
>>> to   do, but it's not very helpful:)  I also noticed that the 
>>> header  parsing  code is essentially duplicated (though in lesser 
>>> form)  inside of  ChunkedInputStream.  I had no idea what footer 
>>> values were  until I came  across that one.  I'm thinking about 
>>> moving the  Header/Footer parsing  and storage code into a whole 
>>> other class and  enhancing it some (adding  ordering, duplicates).  
>>> Do you think this  warrants a new take on the  idea of header 
>>> storage or should the  header storage semantics just be  changed, 
>>> simplified?
>>>
>>> Mike
>>>
>>> On Thursday, January 30, 2003, at 10:38 PM, Jeffrey Dever wrote:
>>>
>>>> Hey Mike,
>>>>
>>>> This is a good one.  I had a fight with the first release prime   
>>>> (Rodney Waldoff) about the compression of multiple headers of the  
>>>> same  type into a single header.  He maintained that it was 
>>>> allowed  by  rfc2616 (which it is) and was therefore OK.
>>>> But if you are using httpclient to check the exact response from 
>>>> the   server, you can't because its munged into somthing else.  It 
>>>> also   makes the friggin header values more difficult to parse.  
>>>> Its kinda   nice having a map of headers, but they are simply not 
>>>> order   preserving.  And comon, do we really need a hashtable to 
>>>> store 5 or  6  entries?
>>>>
>>>> -jsd
>>>>
>>>>
>>>> bugzilla@apache.org wrote:
>>>>
>>>>> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED  
>>>>> COMMENTS  THROUGH THE WEB INTERFACE AVAILABLE AT
>>>>> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12244>.
>>>>> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED  
>>>>> IN  THE BUG DATABASE.
>>>>>
>>>>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12244
>>>>>
>>>>> Response Header ordering not preserved from the server
>>>>>
>>>>> becke@u.washington.edu changed:
>>>>>
>>>>>           What    |Removed                     |Added
>>>>> -------------------------------------------------------------------- 
>>>>> -- ------
>>>>>             Status|NEW                         |ASSIGNED
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>