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 [EMAIL PROTECTED] 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
