Hi Oleg, > As step 4 I moved all param hierarchy building logic from > Http*Connection classes to the corresponding HTTP service classes.
Cool, thanks. > Now, please hear me out. The only place where #setDefaults is being used > outside HttpCore is DefaultClientRequestDirector. Can we _please_ move > those bits of code back to HttpRequestExecutor? This would effectively > encapsulate all param hierarchy building logic inside o.a.http.protocol > package and would enable us to keep it internal to HttpCore protocol > level code. In 3.x, we have at least two hierarchies: global -> client -> host config -> method global -> client -> conn mgr -> connection I still see two cases for hierarchies in 4.x: [application ->] client -> request [application ->] client -> conn mgr Even without application-wide defaults, o.a.h.protocol will not encapsulate _all_ param hierarchy building. I'm thinking of a class ClientParamsStack that has room for at least request-, client-, and application-params. I'm not sure yet how connection manager params fit in. The connection operator expects parameters in method calls. Those could reasonably be made client-specific, with conn mgr params providing defaults. > This also gives up an option to replace the #setDefault > stuff with a solution based on a private class StackedHttpParams or some > such. _Please_ You meant to write "give us" rather than "give up"? If HttpRequestExecutor is the only place in core that still calls setDefaults(), yes, I can live with that. Provided that we update the JavaDocs for HttpParams, indicating that the behavior of setDefaults is implementation dependent. As mentioned above, I expect that params hierarchy building will appear in DefaultHttpClient, in the constructor as well as in the execute methods. The advantage of keeping setDefaults() in core is rather that the NIO code can remain unchanged. > I also would like to remove HttpParams parameter from > HttpClientConnection#receiveResponseHeader and > HttpServerConnection#receiveRequestHeader methods if you do not mind. If those parameters are not used to customize the receive operation, I don't see a need for them. Where are limits for header size and such stuff taken from? cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
