---------------------
PatchSet 11218 
Date: 2007/02/02 17:22:20
Author: adrian
Branch: HEAD
Tag: (none) 
Log:
Fix for reply headers >4k introduced by my last commit.

Unfortunately I didn't take into account that the reply size could be
greater than 4k (ie, one copy.) So temporarily I'm introducing the
following:

* Don't bother trying to reuse the partial body data in the first
  copy in clientSendMoreHeaderData(), just handle the headers that
  we've been given
* Then, in clientCheckHeaderDone(), the check for body data uses
  state->body_buf and state->body_size, which are both 0.
* So it writes out the headers in one comm_write(), then schedules
  another copy through clientWriteComplete().

This is suboptimal - sending headers, waiting for comm_write() to complete,
then sending body data, but it'll only stay this long for as long as it
takes me to remove the reply status+headers from the store memory. Then
the initial read will return headers and some data if available (at store
offset 0 for the data!) and we can once again do it all in one write().

Members: 
	src/client_side.c:1.699->1.700 

Index: squid/src/client_side.c
===================================================================
RCS file: /cvsroot/squid/squid/src/client_side.c,v
retrieving revision 1.699
retrieving revision 1.700
diff -u -r1.699 -r1.700
--- squid/src/client_side.c	2 Feb 2007 09:22:50 -0000	1.699
+++ squid/src/client_side.c	2 Feb 2007 17:22:20 -0000	1.700
@@ -1,6 +1,6 @@
 
 /*
- * $Id: client_side.c,v 1.699 2007/02/02 09:22:50 hno Exp $
+ * $Id: client_side.c,v 1.700 2007/02/02 17:22:20 adrian Exp $
  *
  * DEBUG: section 33    Client-side Routines
  * AUTHOR: Duane Wessels
@@ -2680,20 +2680,29 @@
 	errorAppendEntry(http->entry, err);
 	return;
     }
-    body_size = size - rep->hdr_sz;
-    body_buf = buf + rep->hdr_sz;
-    assert(body_size >= 0);
+    /* 
+     * At this point we might have more data in the headers than this silly 4k read.
+     * So lets just ignore there being any body data in this particular read
+     * (as eventually we won't be issuing a read just to get header data) and issue
+     * our next read at the point just after the reply length in rep->hdr_sz.
+     * Hopefully this horrible hackery will go away once the store API has changed to
+     * seperate entity-data and reply-data. We'll then reinstance the "grab header data
+     * and body data, writing them out in one swift hit" logic which I've just disabled.
+     * - [ahc]
+     */
     http->range_iter.prefix_size = rep->hdr_sz;
-    debug(33, 3) ("clientSendMoreHeaderData: Appending %d bytes after %d bytes of headers\n",
-	(int) body_size, rep->hdr_sz);
     CBDATA_INIT_TYPE(clientCheckHeaderStateData);
     state = cbdataAlloc(clientCheckHeaderStateData);
     state->http = http;
     cbdataLock(http);
-    state->buf = buf;
-    state->size = size;
-    state->body_buf = body_buf;
-    state->body_size = body_size;
+    /* XXX is this state->buf used for anything? Do we free it at all? Wha? [ahc] */
+    state->buf = NULL;
+    state->size = 0;
+    state->body_buf = NULL;
+    state->body_size = 0;
+    assert(state->body_size >= 0);
+    debug(33, 3) ("clientSendMoreHeaderData: Appending %d bytes after %d bytes of headers\n",
+	(int) state->body_size, rep->hdr_sz);
     clientHttpLocationRewriteCheck(state);
 }