Re: svn commit: r535512

[Roland Weber <os...@dubioso.net>]

Hi Oleg,

> retry the request execution in case of an I/O failure without
> re-running HTTP protocol interceptors on the failed request

I like this approach. It avoids the undoing of modifications,
for which I had planned request wrappers. It also seems to
narrow down the scope of retry handling. For example retrying
with a different proxy is out of scope since that could affect
the preparation of the request (I guess).

cheers,
  Roland

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

Re: [HttpClient] Request wrapper vs request copy ; was Re: svn commit: r535512

[Oleg Kalnichevski <ol...@apache.org>]

On Sat, 2007-05-12 at 17:51 +0200, Roland Weber wrote:
> Hi Oleg,
> 
> > We may still need to introduce request wrappers in order to be able to
> > discard all request headers generated by the protocol interceptors when
> > dealing with request redirects, for instance. As an alternative to that
> > we may also think about creating a complete copy of the original request
> > if it gets redirected to a new location. However, there can be other
> > cases where we may want to discard auto-generated request headers
> > without changing any other properties of the request such as request
> > URI.
> 
> I still feel that discarding auto-generated headers is insufficient
> (beyond alpha). Think of an interceptor that folds separate headers
> with identical names into one, or that splits such headers into many.
> Think of another interceptor in a proxy application that inserts an
> entry into a Via: header.

Actually while writing code I realized the two approaches were not all
that different. A request wrapper in its current implementation is
essentially a shallow copy of the original request. This allows headers
to be removed and added without affecting the wrapped request. Only if
an interceptor cast the Header interface to its implementation and
modified the content of the underlying header buffer in some way the
wrapped request would mutate. But I do not think safeguards against such
misuse are worth the cost of making a deep copy of the original request.

Cheers

Oleg


> A copy technique would have to create the copy _before_ the request
> gets modified and sent. We couldn't tell whether there will be a
> redirect or not. Let's keep the "delete auto-generated headers" trick
> for alpha1 and think about alternatives later.
> 
> cheers,
>   Roland
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> 
> 


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

Re: [HttpClient] Request wrapper vs request copy ; was Re: svn commit: r535512

[Roland Weber <os...@dubioso.net>]

Hi Oleg,

> We may still need to introduce request wrappers in order to be able to
> discard all request headers generated by the protocol interceptors when
> dealing with request redirects, for instance. As an alternative to that
> we may also think about creating a complete copy of the original request
> if it gets redirected to a new location. However, there can be other
> cases where we may want to discard auto-generated request headers
> without changing any other properties of the request such as request
> URI.

I still feel that discarding auto-generated headers is insufficient
(beyond alpha). Think of an interceptor that folds separate headers
with identical names into one, or that splits such headers into many.
Think of another interceptor in a proxy application that inserts an
entry into a Via: header.
A copy technique would have to create the copy _before_ the request
gets modified and sent. We couldn't tell whether there will be a
redirect or not. Let's keep the "delete auto-generated headers" trick
for alpha1 and think about alternatives later.

cheers,
  Roland


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

[HttpClient] Request wrapper vs request copy ; was Re: svn commit: r535512

[Oleg Kalnichevski <ol...@apache.org>]

On Sun, 2007-05-06 at 11:45 +0200, Roland Weber wrote:
> Hi Oleg,
> 
> > retry the request execution in case of an I/O failure without
> > re-running HTTP protocol interceptors on the failed request
> 
> I like this approach. It avoids the undoing of modifications,
> for which I had planned request wrappers. It also seems to
> narrow down the scope of retry handling. For example retrying
> with a different proxy is out of scope since that could affect
> the preparation of the request (I guess).
> 
> cheers,
>   Roland
> 

Hi Roland

We may still need to introduce request wrappers in order to be able to
discard all request headers generated by the protocol interceptors when
dealing with request redirects, for instance. As an alternative to that
we may also think about creating a complete copy of the original request
if it gets redirected to a new location. However, there can be other
cases where we may want to discard auto-generated request headers
without changing any other properties of the request such as request
URI.

Oleg

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


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