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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
