Mailing-List: contact httpclient-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient Project" <httpclient-dev@jakarta.apache.org>
Message-ID: <9686344.1151657670643.JavaMail.jira@brutus>
Date: Fri, 30 Jun 2006 08:54:30 +0000 (GMT+00:00)
From: "Oleg Kalnichevski (JIRA)" <jira@apache.org>
To: httpclient-dev@jakarta.apache.org
Subject: [jira] Commented: (HTTPCLIENT-589) Do not consume the remaining
 response content if the connection is to be closed
In-Reply-To: <21695633.1151543431152.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/HTTPCLIENT-589?page=comments#action_12418587 ] 

Oleg Kalnichevski commented on HTTPCLIENT-589:
----------------------------------------------

Odi, Mike, Roland,

I am having a second thought about this patch. Even though it does prove useful in some corner cases, it actually negatively impacts performance in the most common use cases (when the response content has been fully consumed or the connection can be kept alive). The invocation of the HttpMethodBase#shouldCloseConnection method is far from being cheap. With this patch the method gets called twice for every response in the overwhelming number of cases. I suggest this issue be marked as WONTFIX or be dealt with in the 4.0 version.

Oleg

> Do not consume the remaining response content if the connection is to be closed
> -------------------------------------------------------------------------------
>
>          Key: HTTPCLIENT-589
>          URL: http://issues.apache.org/jira/browse/HTTPCLIENT-589
>      Project: HttpComponents HttpClient
>         Type: Improvement

>   Components: HttpClient
>     Versions: 3.1 Alpha 1
>  Environment: All environments
>     Reporter: James Murty
>     Assignee: Oleg Kalnichevski
>      Fix For: 3.1 Beta 1
>  Attachments: HttpMethodBase.java.diff, conn-release.patch
>
> 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: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org