From: Daniel Stenberg <daniel@haxx.se>
Date: Mon, 8 Apr 2002 07:27:22 +0000 (+0000)
Subject: based on Jacky Lam's "HTTP 1.0 304-only" fix, this change makes a 304 reply
X-Git-Tag: curl-7_9_6~39
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=5d28a857a45c5069238377a34c153458c187787a;p=curl

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 5d6f13309..671dba560 100644
--- 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 */