Hi Oleg, I had some more thoughts on the topic, especially since I overlooked the RequestExecutor before. Handling expect/continue in the same location as redirects and authentication was not a good idea from my side. Managing connections with partially sent requests would introduce way too much complexity to result in any kind of improvement. I was aiming at making the connection interface a little more complicated while hiding that from the user, but the changes I suggested would have to be propagated through the RequestExecutor as well, where I don't want them any more than you do. The connections are a little more intelligent than I had expected them to be, I might as well get used to the idea.
Your suggestion to have a sendRequest that never returns a response and a receiveRequest which can be called multiple times if the connection is implemented or configured to return 1xx responses takes us a long way. I am starting to think of expect/continue and 1xx responses as distinct but linked problems. Discarding 1xx responses or giving applications access to them is one thing, and blocking the sending of a request after the header to wait for a 100 or terminal response is another. I don't think that 1xx responses are the same as terminal responses, but I consider them something that should not be completely hidden from an application. That does not necessarily mean they have to be provided in the same way as terminal responses. The cases in which access to a 1xx response will be required are rare. I can image for example a callback interface for delivering 1xx responses, while the terminal response is returned as the result of a method invocation. I am sure we'll find a good solution for this, preferably without different implementations for the connection interface. The blocking part of the expect/continue handshake is something I don't feel comfortable with yet. Saying that, it is inherently synchronous and I intend to simply ignore it for http-async, at least at the beginning. I do have a tendency towards over-designing, but I will try to restrain myself, and you guys can keep me in check if I fail in that :-) cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
