You asked for opinions, here's mine... There is no point maintaining broken stuff, it just leads to more real world misery. Backwards compatible or not. I'd rather if it break at compile/dynamic link time, not runtime (with broken stuff). I want a ubiquitous HttpClient I can rely upon, and it needs to be stable, so it needs to be maintainable, hence clean. Your time is better spent making this clean than fighting mistakes.
Short term pain, long term gain -- that's my view! [I've recently started two re-works, clean-ups -- and I've gotta say ... Yum! Nothing feels better...] regards, Adam P.S. Why can't HttpClient jump to a 3.0? Who cares about time and numbers? In a month [or whatever] folks will look back on working system and not know the difference. Is HttpClient really so ubiquitous it couldn't make a jump? ----- Original Message ----- From: "Oleg Kalnichevski" <[EMAIL PROTECTED]> To: "Jakarata Commons HttpClient mailing list" <[EMAIL PROTECTED]> Sent: Thursday, November 06, 2003 3:40 PM 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]
