JDK-4399527 : HttpUrlConnection should not buffer POST data into memory if Content-Length set
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 1.3.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2000-12-19
  • Updated: 2000-12-21
  • Resolved: 2000-12-21
Related Reports
Duplicate :  
JDK-4363479 - support http 1.1 chunked encoding output
Description

Name: krC82822			Date: 12/19/2000


18 Dec 2000, eval1127@eng -- see also 4333920.
-------------------
bash-2.04$ java -version
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

The HttpUrlConnection should not buffer POST data into memory if
Content-Length [has been] set, as this makes the class unusable when attempting
to post large files via a multipart/form-data post. Right now post
data is buffered into a ByteArrayOutputStream so that the Content-Length
can be calculated. If the Content-Length has been set the post
output stream should just be a pass through stream to the http server.
(Review ID: 113706) 
======================================================================
Comments
WORK AROUND Name: krC82822 Date: 12/19/2000 Write my own http client. ======================================================================
11-06-2004
EVALUATION This bug is essentially suggesting that if the application sets the content-length header field we should recognize it and not buffer the requests. There are two issues with this :- 1. In case of re-directs we need to buffer the entire request and it may be necessary to re-send the request if redirected. However if setInstanceFollowRedirects(false) is used one could argue that no buffering is required. 2. There isn't a method for the application to specify the content length in a request and thus it would be necessary to check for the content-length field set with setRequestProprerty. However this would mean that we the application is trusted to set the right length and this raises complications in cases where the app tries to send more than the length or if the application tries to obtain the input stream before it has sent the entire request to the output stream. However the more general issue is that we do require a way to stream http requests to the server. The right way is to use chunked encoded requests as per the http 1.1 RFC. Based on this I am closing this bug as a duplicate of 4363479 which is our bug to track the requirement to stream http requests to the server. alan.bateman@ireland 2000-12-21
21-12-2000