David Daney <[EMAIL PROTECTED]> writes: > Chris Burdess wrote: >> David Daney wrote: >> >>> It seems the the current implementation of HTTPURLConnection.connect() >>> buffers the entire response before returning. >>> >>> Is that a correct analysis? >> >> >> Yes. >> >>> This can be problematical if the content is larger than the heap. It >>> is even worse than that as it makes a copy of the content, so the >>> content can only be half as large as the heap. >>> >>> Does anyone know the rational behind doing it this way? >> >> >> Our implementation uses the inetlib HTTP client in order to leverage >> numerous HTTP features such as chunked and compressed transfer-codings, >> TLS, and HTTP 1.1. >> > > That is all well and good, however it seems to me that the primary > responsibility of the core implementation of HTTP in classpath is to > provide the same level of support that Sun's implementation has. A > secondary consideration would be to have hooks so that other proprietary > libraries could hook into it to add enhanced non-standard features. > > Crippling classpath so that it fits with the implementation of inetlib > just does not seem right.
It's not really a case of that... Classpath is unusual in having an HTTP/1.1 provider. There is benefit in that. Personally, I think Chris should add a lazy (streaming) interface on top. But there is a thread cost. Nic _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
