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]
