hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <ossf...@dubioso.net>
Subject Re: [HttpCore] HTTP parameters was Re: [HttpConn] test coverage
Date Sun, 27 May 2007 17:18:27 GMT
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: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org


Mime
View raw message