Re: HTTPURLConnection.connect() buffers its entire input.

[Nic Ferrier]

David Daney <address@hidden> 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