Re: [HttpCore] mutability and immutability no more?

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

On Sun, 2006-02-12 at 19:15 +0100, Roland Weber wrote: 
> Hi Oleg, hi all,
> 
> I'm not quite happy with the way http-core currently handles
> mutable vs. immutable messages, in particular requests. There
> is an instanceof check in HttpRequestExecutor: if a request
> is an instance of HttpMutableRequest, it is preprocessed. If
> it is not an instance of that interface, preprocessing is
> skipped. This has some questionable implications:
> 
> - the default implementations we have (HttpGet, HttpPost)
>   implement the mutable interface and can not be protected
>   from being modified (out of the box)
> 
> - if an application implements the non-mutable interface,
>   the skipping of preprocessing will most likely result in
>   an invalid request being sent. In other words:
> 
> - although the signature of HttpRequestExecutor.execute
>   declares to expect an immutable request, it actually
>   requires a mutable request to function properly
> 
> - the design is not "fair", meaning: we implicitly expect
>   applications to respect immutability if we declare a
>   return value with an immutable interface, but our code
>   does not show the same respect towards the application
> 
> Yes, the last three points are more or less the same.
> That just shows you how many facets my unhappiness has :-)
> One other point which seems unrelated at first sight is
> the distinction between auto-generated headers and headers
> provided by the application. In HttpClient < 4.0, this is
> used to "undo" modifications to a request before retrying,
> I think in the method director.
> This design restricts our request interceptors to adding
> headers. Removing a header, or changing a header value,
> are operations that can not be undone. Even if we might
> not provide interceptors that modify header values, the
> mechanism is meant for use by application developers too.
> Not allowing modifications or removal of headers is a
> significant restriction. Some headers for which modifications
> can be useful are Cookie, Connection, Content-Encoding.
> 
> An alternative way to address mutability and immutability
> is through the use of wrappers. I have seen this technique
> applied in similar scenarios. The Servlet API added wrappers
> for requests and responses with version 2.3:
> http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/http/package-summary.html
> 
> The idea is as follows: instead of an instanceof check to
> decide whether request preprocessing should be performed,
> a mutable wrapper is created for the request. Preprocessing
> is *always* performed, modifications apply only to the
> wrapper. The auto-generated flag for Headers is pointless,
> modifications are undone by forgetting about the wrapper.
> Wrappers that implement only the non-mutable interfaces
> can be used to protect against unintentional modifications
> of objects.
> This change is based on a different interpretation of
> "immutable". To me, immutable doesn't mean that a request
> is sent without being processed by the interceptors.
> It means that the object in memory is not modified.
> 
> If you feel like you've got a deja vu now, here's why:
> http://mail-archives.apache.org/mod_mbox/jakarta-httpclient-dev/200503.mbox/%3cOFF61E99BB.5D1DEACB-ONC1256FD3.003C83FB-C1256FD3.003EF2AF@de.ibm.com%3e
> 
> Based on the result of this discussion, I will try to come
> up with a patch next weekend - or not.
> There would be some followup issues because the distinction
> between entity enclosing and header-only requests is currently
> based on another instanceof check. This can be addressed by
> implementing plenty of different wrapper classes, or by
> removing the instanceof check in favor of a flag that can be
> queried. (We don't have different response classes either.)
> But that is a secondary issue to the big question:
> to wrap or not to wrap?
> 

Roland,

Frankly, I do not think this would be a better solution. There are
situations where one does want the original request object to mutate in
order to be able to examine its post-execution state. If we wrapped the
original request object all mutations to it would be lost along with the
wrapper.

I have a more radical change to suggest. I am beginning to suspect the
whole concept of mutable/immutable HTTP messages while being
conceptually nice does not seem to bring any tangible benefits in
practical terms.   

In the very beginning I still thought we might want to stick some of the
protocol logic into HttpRequest/HttpResponse class hierarchy (for
instance 'Host' header), which would require some complex methods
mutating the state of the request objects. This proved unnecessary. Now
we have all HTTP protocol logic neatly encapsulated in the
request/response interceptors and the control logic encapsulated in
various HTTP processors. HTTP messages have been reduced to being pure
value objects, which is great. Probably we ought to start thinking of
HttpRequest/HttpResponse classes as representing value objects, which
are always mutable. 

I suggest we just do away with HttpMutable* interfaces 

Oleg

> 
> I'm signing off now, it's been a long day. Looking forward
> to read your comments tomorrow.
> 
> cheers,
>   Roland
> 
> ---------------------------------------------------------------------
> 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

Re: [HttpCore] mutability and immutability no more?

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

On Mon, 2006-02-13 at 22:50 +0100, Roland Weber wrote:
> Hi Oleg,
> 
> >>>wrapper.
> >>[...]
> > This is perfectly fine for a special case but I am not convinced this
> > should be a part of HttpCore. There are other ways to deal with
> > auto-generated headers.
> 
> We'll discuss them all in due time.
> 
> > My Evil (TM) plan is 
> > (1) Snowboarding while there's still snow ;-)
> 
> Have fun :-)
> 
> > (2) HttpRequestExecutor refactoring followed by
> 
> Ok, I'll review the patch when it is up.
> 
> > (3) HttpMutableStuff refactoring
> 
> Looking forward to it.
> 
> > (4) No more hacking until the HttpComponents site is up
> > 
> > Does this work for you?
> 
> Yep, it does. The refactoring of HttpRequestExecutor/AsyncHttpProcessor
> and the wrapper discussion (now morphed into the removing of mutable)
> were the two major items I wanted to trigger before the http-core alpha
> in March. I'll take things easier for a while, thinking about async
> notifications and maybe adding some stuff to the wiki. I have a few
> days off in March, that's when I want to tackle the async notification.
> 
> cheers,
>   Roland
> 

All right. HttpMutableStuff is no more

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

Re: [HttpCore] mutability and immutability no more?

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

Hi Oleg,

>>>wrapper.
>>[...]
> This is perfectly fine for a special case but I am not convinced this
> should be a part of HttpCore. There are other ways to deal with
> auto-generated headers.

We'll discuss them all in due time.

> My Evil (TM) plan is 
> (1) Snowboarding while there's still snow ;-)

Have fun :-)

> (2) HttpRequestExecutor refactoring followed by

Ok, I'll review the patch when it is up.

> (3) HttpMutableStuff refactoring

Looking forward to it.

> (4) No more hacking until the HttpComponents site is up
> 
> Does this work for you?

Yep, it does. The refactoring of HttpRequestExecutor/AsyncHttpProcessor
and the wrapper discussion (now morphed into the removing of mutable)
were the two major items I wanted to trigger before the http-core alpha
in March. I'll take things easier for a while, thinking about async
notifications and maybe adding some stuff to the wiki. I have a few
days off in March, that's when I want to tackle the async notification.

cheers,
  Roland

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

Re: [HttpCore] mutability and immutability no more?

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

On Mon, 2006-02-13 at 21:41 +0100, Roland Weber wrote:
> Hi Oleg,
> 
> > Frankly, I do not think this would be a better solution. There are
> > situations where one does want the original request object to mutate in
> > order to be able to examine its post-execution state. If we wrapped the
> > original request object all mutations to it would be lost along with the
> > wrapper.
> 
> It's available as the "request" attribute in the HttpContext,
> until the next request is sent (HttpRequestExecutor) or until
> the handle is garbage collected (HttpDispatcher).

Hi Roland

This is perfectly fine for a special case but I am not convinced this
should be a part of HttpCore. There are other ways to deal with
auto-generated headers.

> 
> > I have a more radical change to suggest. I am beginning to suspect the
> > whole concept of mutable/immutable HTTP messages while being
> > conceptually nice does not seem to bring any tangible benefits in
> > practical terms.   
> > [...]
> > I suggest we just do away with HttpMutable* interfaces 
> 
> That will be a significant simplification of the interface as well
> as the implementation. It doesn't address the undo/revert problem,
> but that doesn't need to be solved until we start to authenticate
> or to chase redirects.
> 
> Are you going to implement that?
> 

I will take care of that, but not immediately. I would like to take a
day off tomorrow and spend it in the mountains snowboarding. So,
probably sometime around this Friday. Besides, your refactoring of
HttpRequestExecutor must to go in first, however I do not think it is
quite ready yet.

My Evil (TM) plan is 
(1) Snowboarding while there's still snow ;-)
(2) HttpRequestExecutor refactoring followed by
(3) HttpMutableStuff refactoring
(4) No more hacking until the HttpComponents site is up

Does this work for you?

Oleg


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

Re: [HttpCore] mutability and immutability no more?

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

Hi Oleg,

> Frankly, I do not think this would be a better solution. There are
> situations where one does want the original request object to mutate in
> order to be able to examine its post-execution state. If we wrapped the
> original request object all mutations to it would be lost along with the
> wrapper.

It's available as the "request" attribute in the HttpContext,
until the next request is sent (HttpRequestExecutor) or until
the handle is garbage collected (HttpDispatcher).

> I have a more radical change to suggest. I am beginning to suspect the
> whole concept of mutable/immutable HTTP messages while being
> conceptually nice does not seem to bring any tangible benefits in
> practical terms.   
> [...]
> I suggest we just do away with HttpMutable* interfaces 

That will be a significant simplification of the interface as well
as the implementation. It doesn't address the undo/revert problem,
but that doesn't need to be solved until we start to authenticate
or to chase redirects.

Are you going to implement that?

cheers,
  Roland

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