hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kalnichevski, Oleg" <oleg.kalnichev...@bearingpoint.com>
Subject RE: FW: [PATCH] PreEmptive authentication setting
Date Tue, 21 Jan 2003 12:46:19 GMT

Consider adding pre-emptive authentication flag to the HttpState class as an interim solution.
It may not be the most elegant one, however, it appears more appropriate (at least to me)
than adding such flag to the HttpConection class. In this case you would not need to modify
any interface or even method signature as the Authenticator class works with HttpState instances



> Hello,
> In this case: Should we apply the patch, which gives the client/application
> the possibility to control the preemptive setting and re-fix those
> getter/setter during the architectural change?
> Best regards

 -----Original Message-----
From: 	Ortwin Gl├╝ck [mailto:ortwin.glueck@nose.ch] 
Sent:	Friday, January 17, 2003 16.41 PM
To:	Commons HttpClient Project
Subject:	Re: FW: [PATCH] PreEmptive authentication setting

Kalnichevski, Oleg wrote:
> Odi, I also tend to disagree with your idea of making HttpMethod
> aware of its HttpClient. That would make these two classes tightly
> coupled which is generally a bad idea. 

I agree completely.

 > Clearly HttpMethod derived
> classes need to know a whole set of parameters that affect their mode
> of execution. I would rather see HttpClient pass onto its HttpMethods
> an instance of a configuration class (similar in a way to
> HostConfiguration class) that define various aspects HttpMethod's
> behavior.

Yep. This was discussed here a couple of times and is the point of the 
new preferences architecture as described in bug 15435:

> Laura, Good point. I just want to suggest we rethink the overall
> design of the HttpClient once we get release 2.0 out of the door,
> rather than attempt to patch various shortcomings of the existing
> design

Jeff has clearly stated earlier, that this architecture change should 
happen after 2.0 (so target of that bug is 2.1)

View raw message