hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roland Weber" <ROLWE...@de.ibm.com>
Subject Re: HttpClient Revolutions
Date Fri, 07 Nov 2003 06:41:25 GMT
Hi Oleg,

the urge to take something apart and put it back together
the way it should be is something I can sympathize with.
But, as Mike pointed out, the idea was to keep the bad
stuff for this release and do the overhaul for the next one.
I think if you can hang on through these hard times, you'll
have even more fun once you get started on 3.0.

As for the problem at hand, here is one suggestion:
Currently, you are keeping all headers in the same place
and try to throw out the auto-generated ones to clean up.
Instead, you could collect the manually set headers in a
dedicated place. When headers get generated, you start
by copying them into an empty header set, then adding
those that need to be generated to that new set. Cleanup
reduces to throwing away the generated set.

cheer up!

Oleg Kalnichevski <olegk@apache.org>
06.11.2003 23:40
Please respond to "Commons HttpClient Project"
        To:     Jakarata Commons HttpClient mailing list 
        Subject:        HttpClient Revolutions

This is one of those days when my frustration with the existing
HttpClient architecture reaches the point when I can hardly fight off
the idea of stating a fork at SourceForge in order to finally get the
very basic things right. I am really getting tired of patching the
deficient architecture and bending it in all sorts of creative ways.

I was trying to provide a fix for the bug that I introduced with one of
my recent patches (authentication headers created by HttpMethodDirector
end up removed in HttpMethodBase). The nasty thing is that since headers
can be added to the HTTP method in several places, it is not quite clear
at what point auto-generated headers are safe to be removed. If the
auto-generated are cleaned up in the authentication/redirect loop, then
they are not cleaned up in case of automatic recovery from a transport
exception. As a result cookie headers can be duplicated. If the
auto-generated headers are cleaned inside the retry loop, authentication
headers are not re-generated in case of the method retry.

So, once again the real trouble is the ugly design of the HttpMethod
interface/HttpMethodBase class. The decision to recreate request headers
every time the method is being executed was ill-conceived, not to
mention that this is not quite efficient. 

I strongly believe that the process of request assembly and request
execution should be decoupled. I suggest the
generateRequstHeaders(HttpState, HttpConnection) method be added to the
HttpMethod interface. The only problem that concerns me is that this may
be too much of a change for 2.1 release, and I once again will end up
accused of all sorts of things ranging from not caring about backward
compatibility to deliberately breaking other people's stuff. Actually
applications that only use public HttpClient APIs will not be affected,
but classes implementing HttpMethod interface will be broken.

Let me know what's your feeling about this

I'm off to bed


To unsubscribe, e-mail: 
For additional commands, e-mail: 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message