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-07-23 04:06 ------- > * In particular I like the idea of HttpMethodSession (maybe just HttpSession?). > I would make an interface out of it, however, as in the future we may give users > an option to provide a pluggable custom implementation of the HTTP session. I agree the name is not good. HttpSession is already is use in javax.servlet so I would suggest against that as well. Any other ideas? We could certainly move "HttpMethodSession" to an interface. I would like to wait a little on that though. I imagine it will be changing quite a bit for a while and I do not want to expose something so volatile. > * I would not deprecate 'used' flag as yet. I helps prevent the user from > executing the same method multiple times and getting ambiguous results. In the > future (3.0) this flag should disappear along with the entire concept of method > recycling. The problem is that this also keeps HttpMethodSession from executing a method more than once. We could add a hack to HttpMethodBase to override used in HttpMethodSession but that would be a little nasty. > * I would pass state & connection manager as HttpMethodSession's constructor > parameters. We, then, later may completely do away with those setter methods > (setSoTimeout, setConnectionTimeout, setHttpConnectionFactoryTimeout and so on), > as I think we should be using a hash map to store HttpClient preferences instead > of just keeping on extending APIs with all those numerous options. I'll expand > later on this point when we get to discuss the new preferences architecture. My impression was that preferences would mostly be just for default values. Do you envision the ability to create a custom set of preferences for each method execute? My preference would be to leave these alone for now until we know what the preferences will look like. If we keep HttpMethodSession hidden for now we won't have to look at the ugliness. > * I would also provide Header[] getRequestHeaders(String) at the very least for > the sake of API completeness. I agree. > + if (method instanceof HttpMethodBase) { > + return ((HttpMethodBase) method).getMethodRetryHandler(); > + } else { > + return new DefaultMethodRetryHandler(); > + } > * IMHO things like that should strongly hint at some design improvements. Do you > think there is way doing without that ugly HttpMethodBase cast? I would suggest > adding getMethodRetryHandler to HttpMethod interface, if there are no other > alternatives Yes, this is not pretty. There are a number of places where things are accessible from HttpMethodBase but not HttpMethod. In general we have 3 options for these cases: 1) do a nasty hack like above 2) move the methods to HttpMethod 3) deprecate/remove the code So far I have been leaning towards 1 and 3 so that HttpMethod does not have to be changed too much. Having said that I wonder if anyone is implementing HttpMethod directly. Especially when considering how complicated HttpMethodBase is. Though I understand the general appeal of interfaces I wonder if the HttpMethod interface is really necessary. I do not expect that we will remove HttpMethod any time soon but I wonder if we should worry about making additions to it. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
