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
[EMAIL PROTECTED] 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
[EMAIL PROTECTED] changed:
What |Removed |Added
-------------------------------------------------------------------- -- ------
Status|NEW |ASSIGNED
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
