You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2007/05/13 12:09:12 UTC

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

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