Odi, Roland, Mike, and Adam Thanks for the feedback. I took another look at the code this morning and had to concede that any half-measure would hardly make things better (or cleaner). Until HttpMethod interface is split into HttpRequest/HttpResponse pair, decoupling of request assembly and request execution logic does not make a lot of sense.
No revolution for now. Especially on November the 7th. The previous one did little good. I'll provide a fix for the bug sometime this weekend. No API changes will be involved. Cheers Oleg On Fri, 2003-11-07 at 07:41, Roland Weber wrote: > 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! > Roland > > > > > > > Oleg Kalnichevski <[EMAIL PROTECTED]> > 06.11.2003 23:40 > Please respond to "Commons HttpClient Project" > > To: Jakarata Commons HttpClient mailing list > <[EMAIL PROTECTED]> > cc: > Subject: HttpClient Revolutions > > > Folks, > 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 > > Oleg > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
