This is the mail archive of the
java-prs@gcc.gnu.org
mailing list for the Java project.
[Bug libgcj/26487] Weird handling of HTTP Headers
- From: "ddaney at avtrex dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: java-prs at gcc dot gnu dot org
- Date: 1 Mar 2006 17:10:28 -0000
- Subject: [Bug libgcj/26487] Weird handling of HTTP Headers
- References: <bug-26487-12276@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot 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