hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <be...@u.washington.edu>
Subject Re: HttpClient Revolutions
Date Fri, 07 Nov 2003 04:51:55 GMT
Hi Oleg,

No need to be frustrated.  As has been the case since we started work 
on "2.1" our plan for backwards compatibility has been to keep as much 
as we can.  We have already made a number of changes in 2.1 that could 
potentially cause trouble for users.  I think must continue to try to 
make as few API breaking changes as possible.  In the end we will call 
it either 2.1, 2.5, or 3.0 depending on the changes.

As for this current question I haven't looked at it closely enough to 
offer anything useful, but I will think about it some tomorrow.

Mike

On Nov 6, 2003, at 5:40 PM, Oleg Kalnichevski wrote:

> 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: 
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: 
> commons-httpclient-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org


Mime
View raw message