[ http://issues.apache.org/jira/browse/HTTPCLIENT-589?page=comments#action_12418460 ]
Oleg Kalnichevski commented on HTTPCLIENT-589: ---------------------------------------------- > I initially tried both the HttpMethod#abort and releaseConnection methods but > both end up calling close on the response input stream With all due respect I do not think this observation is correct. See for yourself: http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpclient/HttpMethodBase.html#1008 > I suppose the releaseConnection method could be changed to perform > differently in the case where the ContentLength wrapper is used, but it seems > easier not to add this wrapper in the first place rather than working around > it later on It's been a conscious design decision on our part that the consumer of HttpClient must not be able to close the underlying socket stream directly and I personally want to keep it this way. Besides, this problem has nothing to do with the content-length delimited content streams. The problem equally affects chunk-encoded content streams. If the server responds with 'connection: close' there's no point in reading the stream to the end of stream regardless whether it is content-length delimited or chunk encoded. I hope this will point you in the right direction. Oleg > Avoid wrapping server responses in ContentLengthInputStream when client or > server sets the Connection:close directive > --------------------------------------------------------------------------------------------------------------------- > > Key: HTTPCLIENT-589 > URL: http://issues.apache.org/jira/browse/HTTPCLIENT-589 > Project: HttpComponents HttpClient > Type: Improvement > Components: HttpClient > Versions: 3.0.1 > Environment: All environments > Reporter: James Murty > Attachments: HttpMethodBase.java.diff > > I am working on a HttpClient-based application to send and receive > potentially large files (up to Gigabytes). When receiving large files the > application allows the user to cancel the download, at which time it closes > the response input stream behind the scenes. > The input stream currently provided by HttpMethodBase.getResponseBody() for > un-chunked responses with a known content length is a > ContentLengthInputStream, which automatically reads the remainder of the > wrapped response instead of closing it straight away. This behaviour does not > work well with very large files as the data is downloaded unnecessarily and > the connection is held open for long very periods. > Per the HTTP 1.1 spec section 14.10 it seems to me that either a server or a > client in an HTTP 1.1 connection can use the Connection:close directive to > signal that a connection will be non-persistent, and will therefore not > require that all data be read before the connection can be released (the > cleaning up ContentLengthInputStream performs for persistent connections). > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.10 > Could HttpMethodBase be modified to check for this directive, from the server > or client, and avoid wrapping the response input stream in > ContentLengthInputStream when it is present? It seems straight-forward, > though there may be side-effects I am not aware of. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
