It appears that around line 360-ish in ProxyHandler.java, the URLConnection output stream isn't being closed after the request is written to it:


            if (hasContent) {
                connection.setDoOutput(true);
                IO.copy(in, connection.getOutputStream());
            }


In examples I'm seeing on the web, the stream is closed after writes, sometimes with a flush() too. Unless IO.copy() automatically closes the stream after writing to it ... where the heck is IO.copy from again???

Also, same thing later in the file with ModifiedIO.copy(); the output stream isn't being closed.

Ok, my previous comment was a red herring. I found the root cause.

ProxyHandler.java uses some logic to determine whether a given request has content:


    if (HttpFields.__ContentType.equals(hdr) && !"GET".equals(request.getMethod()))


If the request does NOT contain the "Content-Type" header, the RC assumes (perhaps erroneously) that the request does NOT contain content. What's the workaround? Well, you could simply make sure the request has the "Content-Type" header ... using setRequestHeader() for requests created in javascript, for example. We could also enhance the logic in ProxyHandler.java to consider the "Content-Length" header too, which might be present even if "Content-Type" isn't. This is the case for certain requests begin sent by IE. Here's a patch for that:


Index: ProxyHandler.java
===================================================================
--- ProxyHandler.java (revision 2068)
+++ ProxyHandler.java (working copy)
@@ -304,6 +304,7 @@

         // copy headers
         boolean xForwardedFor = false;
+ boolean isGet = "GET".equals(request.getMethod());
         boolean hasContent = false;
         Enumeration enm = request.getFieldNames();
         while (enm.hasMoreElements()) {
@@ -315,7 +316,7 @@
             if (connectionHdr != null && connectionHdr.indexOf(hdr) >= 0)
                 continue;

- if (HttpFields.__ContentType.equals(hdr) && !"GET".equals(request.getMethod()))
+ if (!isGet && HttpFields.__ContentType.equals(hdr))
                 hasContent = true;

             Enumeration vals = request.getFieldValues(hdr);
@@ -326,6 +327,9 @@
                     if ("Referer".equals(hdr) && (-1 != val.indexOf("/selenium-server/"))) {
                         continue;
                     }
+ if (!isGet && HttpFields.__ContentLength.equals(hdr) && Integer.parseInt(val) > 0) {
+ hasContent = true;
+ }

                     connection.addRequestProperty(hdr, val);
                     xForwardedFor |= HttpFields.__XForwardedFor.equalsIgnoreCase(hdr);

That makes sense. You may note that I touched this line in revision 1939 to fix SRC-132. In hindsight, I think it's pretty weird that the ProxyHandler used ContentType to determine whether the request was a POST request or not.

Feel free to check this in...

Commit 2070 includes the patch.