[Bug libgcj/26487] Weird handling of HTTP Headers

["ddaney at avtrex dot com" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #10 from ddaney at avtrex dot com  2006-03-01 17:10 -------
Subject: Re:  Weird handling of HTTP Headers

ifoox at redhat dot com wrote:
> ------- Comment #9 from ifoox at redhat dot com  2006-03-01 16:11 -------
> Hi David,
> 
> I tried to get classpath and try out applying the patch to test it out, but I
> had some problems with it. I'll try again in a bit but I have some general
> comments in the meanwhile.
> 
> It seems more appropriate to keep the headers in a Map than a List, especially
> since getHeaderFields() has to return a map, and most opeartions are just a
> simple getHeaderField(sometype). It seems that a LinkedHashMap (which Headers
> extends) should be able to handle same-name headers, because it will just chain
> them together. In theory :)
> 
> If this doesn't work out, it might be possible to store it in a Map in a
> structure like: String -> [String, String, ...] where [] is a List. So we would
> always have a String to List mapping and the List may contain 1 or more values
> for that header.
> 
> Does that make any sense? :)

You should be able to check-out the classpath HEAD and apply the patch 
to that.  Then copy the entire gnu/java/net/protocol/http directory 
contents directly into the corresponding place in the classpath 
directory of libgcj and rebuild.

My first attempt at fixing was to do as you suggested.  The problem is 
that you lose the order of the headers in the case where there were more 
than one header of the same name.  Enumerating the headers in the manner 
of your test program becomes quite complicated.  In the general case, 
the ability to delete some headers complicates things further.

I gave up and went down the road of a somewhat simpler implementation at 
the expense of lookup overhead.  In most cases there are fewer than 
about a dozen headers, so linear searching an ArrayList should not be 
too bad.

I think I will get a second opinion from Tromey et al. ...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26487