hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 16729] - Allow redirects between hosts and ports
Date Tue, 12 Aug 2003 00:20:35 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16729>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16729

Allow redirects between hosts and ports





------- Additional Comments From becke@u.washington.edu  2003-08-12 00:20 -------
Hi Laura,

Thank you for your comments.  Everything you have mentioned should be put on the HttpClient

TODO list, most of them for the near future.

> * It's a bit ugly that HttpMethodDirectory has to be default-constructed and
> then have all its properties set with "set" methods, because this means you can
> get it into an inconsistent state fairly easily.  But since it's not an API
> class, it doesn't matter right now.

I definitely agree.  We should look at a better option for this and other configuration needs
before 
long.

> * As Oleg said, getMethodRetryHandler is disgusting, but you knew that already.
> :-)  Since HttpMethod is a mess and will probably go away in 3.0 (I hope), it's
> probably OK to leave it this way for now.  The retry handler could also go into
> a configuration object, but that would make it global and I think clients need
> the flexibility to change it for individual methods.

Yup, that's pretty much the situation.  It's ugly but I think we need to keep it for now.

> * Should realms and proxyRealms be lazy-allocated?  It's probably a premature
> optimization, but I thought I'd throw it out there.

We certainly could.  They are actually never read at the moment so we could be really lazy
and 
never allocate them :) This is something that should get worked out after some refactoring.
 I just 
left them in as a reminder.

> * The CustomHttpConnection example is now using a deprecated ConnectMethod
> constructor.

Yes, we probably want to rework or remove this example then.

> * TestGetMethodLocal is calling a now-deprecated method on HttpMethodBase

We should remove that once we have a replacement. It might have to wait until we do the request/
response split.

> * What's the "locked" property on HttpConnection used for?  That sort of
> modality in an object can be confusing.  I couldn't find anyone who sets it to
> true, though.

Yes, it's a bit of hidden magic.  It's there to prevent a connection from getting released
between 
method retries.  Previously this was handled by the inExecute flag of HttpMethodBase but that
was 
no longer possible once retries were moved.  We should definitely look at a better solution
for this.  

I believe it is set to true in only one place(HttpMethodDirector.establishValidOpenConnection()).

> Like I said, it looks good.  I don't have any objection to checking it in.
> * I like what you did with ConnectMethod

Thank you.  I appreciate all of the constructive comments.

Mike

Mime
View raw message