JDK-5026745 : Cannot flush output stream when writing to an HttpUrlConnection
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 1.3.0,1.3.1,5.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_nt,windows_2000
  • CPU: generic,x86
  • Submitted: 2004-04-05
  • Updated: 2017-05-16
  • Resolved: 2004-05-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
5.0 b50Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
###@###.### 2004-04-05

The CAP member has a requirement to support signing/encryption for large 
file upload using their Security Applet, i.e. they would like require
support for chunked uploads using the URL connection. Hence would request
to re-open bug(4212479). In this bug, this problem would be fixed if talking
to HTTP1.1 compliant servers.   However even when talking to HTTP1.1. servers,
they still have the same problem.

J2SE Version (please include all output from java -version flag):
  java version "1.5.0-beta2"
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta2-b42)
  Java HotSpot(TM) Client VM (build 1.5.0-beta2-b42, mixed mode)

Does this problem occur on J2SE 1.3, 1.4 or 1.4.1?  Yes / No (pick one)

Bug Description: 
  When writing to an HttpUrlConnection through a DataOutputStream, the call 
to flush() does not actually flush the stream. Internally the data
continues to be buffered until the stream is closed. If you are uploading
large amounts of data then the buffer will eventually grow larger than heap
size and the app will bail with the message "java.lang.OutOfMemoryError:
Java heap space" (JDK 1.5 beta2 b42). 

Recommended behaviour: 
  If the stream is flushed before it is closed, and no content length is set,
then implement HTTP 1.1 Transfer-Encoding=chunked in the client. This will prevent the app from hitting the heap size limit.

Other comments: 
  increasing the heap space is not an option since customers are
running in an applet environment. BTW J2ME already implements HTTP 1.1
chunked transfer encoding in this scenario.  Why can't it also be made
avaible in the PC browser environement

Test code:
//package chunkingtestapplication;

import java.io.*;
import java.net.*;

public class ChunkTester extends Thread {
    ChunkTester(String fileName) {
        m_fileName = fileName;
    //Main method
    public static void main(String[] args) throws Exception {  
        if (args.length != 1)  {
            System.out.println("Usage: ChunkEncodedPost <file>");
            System.out.println("<file> - full path to a file to be posted");
        ChunkTester threadA = new ChunkTester(args[0]);
public void run() {

    try {
        // Open the file
        FileInputStream in = new FileInputStream(new File(m_fileName));

        // Set up the connection
        URL url = new URL("http://localhost:80/chunkyserver");
        HttpURLConnection conn = (HttpURLConnection) url.openConnection();
        conn.setRequestProperty("Transfer-Encoding", "chunked" );

        // Write the file data to the connection in parts
        DataOutputStream dos = new DataOutputStream( conn.getOutputStream()
        byte[] buffer = new byte[2048];

        int readLength;
        while ((readLength = in.read(buffer)) != -1) {
            dos.write(buffer, 0, readLength);
            dos.flush(); // *does not actually flush*

        // close streams
    catch (Exception e) {
    private String m_fileName = null;

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-b50 tiger-beta2

EVALUATION Fixed in tiger b50 ###@###.### 2004-05-13