---------------------
PatchSet 1893 
Date: 2005/09/28 20:29:50
Author: dwsquid
Branch: squid3-icap
Tag: (none) 
Log:
Fix some bugs in processReplyHeader()
- as noted in the comments, there was a HttpReply leak
- MemBuf now has a terminate() method, so we don't have to di the hard way

Members: 
	src/http.cc:1.49.2.29->1.49.2.30 

Index: squid3/src/http.cc
===================================================================
RCS file: /cvsroot/squid-sf//squid3/src/http.cc,v
retrieving revision 1.49.2.29
retrieving revision 1.49.2.30
diff -u -r1.49.2.29 -r1.49.2.30
--- squid3/src/http.cc	28 Sep 2005 20:27:44 -0000	1.49.2.29
+++ squid3/src/http.cc	28 Sep 2005 20:29:50 -0000	1.49.2.30
@@ -1,6 +1,6 @@
 
 /*
- * $Id: http.cc,v 1.49.2.29 2005/09/28 20:27:44 dwsquid Exp $
+ * $Id: http.cc,v 1.49.2.30 2005/09/28 20:29:50 dwsquid Exp $
  *
  * DEBUG: section 11    Hypertext Transfer Protocol (HTTP)
  * AUTHOR: Harvest Derived
@@ -688,7 +688,7 @@
     }
 }
 
-/* rewrite this later using new interfaces @?@
+/*
  * This creates the error page itself.. its likely
  * that the forward ported reply header max size patch
  * generates non http conformant error pages - in which
@@ -697,14 +697,9 @@
 void
 HttpStateData::processReplyHeader(const char *buf, int size)
 {
-    /* Creates a blank header. If this routine is made incremental, this will
-     * not do. XXX: is not this routine called more than once if we do not
-     * have enough buffered data to parse the header? Leaking "reply"s?
-     */
     reply = httpReplyCreate();
     Ctx ctx = ctx_enter(entry->mem_obj->url);
-    debug(11, 3) ("processReplyHeader: key '%s'\n",
-                  entry->getMD5Text());
+    debug(11, 3) ("processReplyHeader: key '%s'\n", entry->getMD5Text());
 
     if (reply_hdr->isNull())
         reply_hdr->init();
@@ -722,7 +717,8 @@
         flags.headers_parsed = 1;
         reply_hdr->clean();
         // negated result yields http_status
-        failReply (reply, error);
+        failReply (reply, error);	// consumes reply
+        reply = NULL;
         ctx_exit(ctx);
         return;
     }
@@ -730,21 +726,13 @@
     if (!parsed) { // need more data
         assert(!error);
         assert(!eof);
-        // XXX: the comment above says this routine is not incremental, yet
-        // we are returning without destroying "reply" as if we expect to
-        // be called again. Benign, leak, or worse?
+        httpReplyDestroy(reply);
+        reply = NULL;
         ctx_exit(ctx);
         return;
     }
 
-    // parsing success
-    assert(parsed);
-
-    const size_t hdr_size = reply->hdr_sz;
-
-    assert(0 < hdr_size && hdr_size <= (size_t)size);
-
-    reply_hdr->buf[hdr_size] = '\0';
+    reply_hdr->terminate();
 
     flags.headers_parsed = 1;
 
@@ -767,6 +755,7 @@
      * of the ICAP pipe buffer for the first HTTP reply read
      * from the network.
      */
+
     if (doIcap() < 0) {
         /*
          * XXX Maybe instead of an error page we should