[ http://issues.apache.org/jira/browse/HTTPCLIENT-589?page=comments#action_12418455 ]
James Murty commented on HTTPCLIENT-589: ---------------------------------------- Ortwin, Sorry for the bad patch. I'll submit a better version once I can confirm it runs correctly against the latest SVN version and test cases. Oleg, I initially tried both the HttpMethod#abort and releaseConnection methods but both end up calling close on the response input stream, and if this input stream is the ContentLengthInputStream it will block until the whole response is read. 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. The advantage of leaving the input stream unwrapped in the Connection:close case is that methods like abort and releaseConnection then close down the stream immediately without any further changes. The proposed changes act much like the existing code for the case when the response length is unknown. However, I don't have a good understanding of how this approach might affect other aspects of the client so there could well be problems I don't appreciate... > 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]
