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