hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [http-common] A short progress report
Date Tue, 29 Mar 2005 14:55:27 GMT
Hi Roland

HttpClient 3.0 already implements option b (to an extent) by marking
generated headers with a special flag and cleaning them up prior to
retrying the request. This will not help in case of request URI
rewriting or request entity modification, of course, but may well be
sufficient for http-common.

I am personally of opinion that request object cloning is simply not
worth the trouble. I tend to like the object factory pattern better.
This said, the option c may be the only way to go when executing
requests asynronosly. We certainly do not want to allow request
mutations while the request is being executed.

Cheers,

Oleg

PS: it is good to have you back


On Tue, Mar 29, 2005 at 01:29:37PM +0200, Roland Weber wrote:
> Hello Oleg, all,
> 
> I think we need to discuss how the request and response objects will
> be used, in particular who is allowed to modify them at which times.
> A client application will prepare an HttpRequest. When that request
> is sent, some filters generate additional headers. A sequence handler
> or retry handler may want to access the original request, or the one
> that is ultimately sent. The application may want to send a modified
> request, possibly in parallel to an asynchronous execution already
> in progress.
> 
> Here are some usage patterns that come into my mind:
> 
> a) Filters modify the original request object. Applications have to
>    clone the request object before sending if they want to generate
>    a modified request. Sequence or retry handlers will not have a
>    chance to get the original request without the modifications.
> 
> b) Filters modify the original request object. The request object 
>    tracks what changes have been applied after a particular point in
>    time, and there is a "cloneOriginal" operation that returns a
>    clone of the request as it was before the modifications.
> 
> c) A wrapper is put around the original request object, modifications
>    are applied only to the wrapper. The wrapper provides access to
>    the original object. Applications have to clone the request object,
>    but can do that while a method execution is in progress.
> 
> d) A wrapper is put around a clone of the original request object,
>    modifications are applied to the wrapper, which provides access
>    to the clone. An application can modify the original object at
>    any time after the method execution has been initiated.
> 
> My preference is option c, followed by b. But there could be others
> I didn't think of. Or there are too many "may want"s in my reasoning
> to justify the additional effort compared to option a. Anyway, I feel
> that the headers generated or modified automatically should be kept
> separate from those provided by the application.
> 
> What do you think?
> 
> cheers,
>   Roland
> 
> 
> 
> 
> 
> 
> Oleg Kalnichevski <olegk@apache.org> 
> 28.03.2005 23:07
> Please respond to
> "HttpClient Project"
> 
> 
> To
> HttpClient Project <httpclient-dev@jakarta.apache.org>
> cc
> 
> Subject
> [http-common] A short progress report
> 
> 
> 
> 
> 
> 
> Folks,
> 
> Unfortunately I was unable finish everything I had hoped to get done by
> the end of the Easter break. However there's already enough code in SVN
> trunk <https://svn.apache.org/repos/asf/jakarta/httpclient/trunk/http-
> common/> to be able to see how things are shaping up. I'll call for a
> formal review as soon as I have the code in a more or less consistent
> state, and a few examples to demonstrate the core functionality. This
> said please do feel free to take a thorough look at what I have done so
> far and give me an early feedback, especially if you feel something is
> not right. 
> 
> Oleg
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


Mime
View raw message