------- 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