based on Jacky Lam's "HTTP 1.0 304-only" fix, this change makes a 304 reply

always stop reading after the headers no matter what 'close' is.

diff --git a/lib/transfer.c b/lib/transfer.c
index 5d6f13309bea445e976d8f6c021c4df68e0bbde3..671dba560fcc1b988d525f9f3ad7b9edf279c384 100644 (file)
--- a/lib/transfer.c
+++ b/lib/transfer.c
@@ -366,15 +366,12 @@ CURLcode Curl_readwrite(struct connectdata *conn,
                    reading! */
                 if(-1 != conn->size)
                   conn->maxdownload = conn->size;
-
-                /* If max download size is *zero* (nothing) we already
-                   have nothing and can safely return ok now! */
-                if(0 == conn->maxdownload)
-                  stop_reading = TRUE;
-                    
-                /* What to do if the size is *not* known? */
               }
-
+              /* If max download size is *zero* (nothing) we already
+                 have nothing and can safely return ok now! */
+              if(0 == conn->maxdownload)
+                stop_reading = TRUE;
+                    
               if(stop_reading) {
                 /* we make sure that this socket isn't read more now */
                 k->keepon &= ~KEEP_READ;
@@ -447,6 +444,7 @@ CURLcode Curl_readwrite(struct connectdata *conn,
                  * NOT contain a message-body, and thus is always terminated
                  * by the first empty line after the header fields.  */
                 conn->size=0;
+                conn->maxdownload=0;
                 break;
               default:
                 /* nothing */