Hi all, I have reached a first milestone. The MTHCM is copied to ThreadSafeClientConnManager and compiles without a reference to HttpHostConnection or HttpConnectionManager. Theoretically, the API is sufficient to use direct connections or non-secure proxy connections without authentication. But writing an example that actually does it is another milestone :-)
There is one gaping hole however: SimpleHttpConnectionManager.finishLastResponse(connection) This concept does not map to the new API, and I'd like to discuss our options before hacking it in. I see the following situations in which a connection can be released: 1. no attempt has been made to communicate => no response to consume, connection CAN be re-used 2. request sent partially, for example only the header => connection MUST NOT be re-used 3. request sent completely, response not received => connection COULD be re-used after consuming the entity, but probably shouldn't since we'd have to interpret parts of the response to determine whether there is an entity 4. request sent completely, response header received partially => same as 3 5. req. s. c., rsp. header received completely, no entity => connection CAN be re-used, nothing needs to be consumed 6. req. s. c., rsp. entity received partially or not at all => connection COULD be re-used after consuming the entity 7. req. s.c., rsp. received completely => connection CAN be re-used, nothing needs to be consumed The code in SimpleHttpConnectionManager deals with situations 1, 5, 6, and 7. I'd have to dig into HttpClient 3.x to tell how 2-4 are dealt with there. I don't like the idea of trying to detect the current situation under the cover. I would prefer to add a few methods replacing the original setLastResponse() and expect the application or HttpClient to call these appropriately. Maybe add some flag under the cover to detect read/write on the connection, so we can tell if the connection is released after a communication attempt without a call to one of the indicator methods. We might go as far as expecting the application or HttpClient to consume the response before the connection is released if re-use is desired. What do you think? cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
