Here's the patch - one extra line necessary to make the comparison actually work. Shall I file a squid bug for ecap modules removing Content-Length with this patch attached? After patching, squid properly caches an adapted response with a different content length from the virgin response. With Vary: Accept-Encoding coming from the underlying webserver, I get N variants cached, which is expected for just the basic Vary support in squid 3, I believe. diff -urp squid-3.1.10/src/adaptation/ecap/Host.cc squid-3.1.10-ecap-patched/src/adaptation/ecap/Host.cc --- squid-3.1.10/src/adaptation/ecap/Host.cc 2010-12-22 00:46:56.000000000 -0500 +++ squid-3.1.10-ecap-patched/src/adaptation/ecap/Host.cc 2011-02-03 13:27:41.000000000 -0500 @@ -25,6 +25,7 @@ Adaptation::Ecap::Host::Host() // this code can run only once libecap::headerReferer.assignHostId(HDR_REFERER); + libecap::headerContentLength.assignHostId(HDR_CONTENT_LENGTH); libecap::protocolHttp.assignHostId(PROTO_HTTP); libecap::protocolHttps.assignHostId(PROTO_HTTPS); diff -urp squid-3.1.10/src/adaptation/ecap/MessageRep.cc squid-3.1.10-ecap-patched/src/adaptation/ecap/MessageRep.cc --- squid-3.1.10/src/adaptation/ecap/MessageRep.cc 2010-12-22 00:46:56.000000000 -0500 +++ squid-3.1.10-ecap-patched/src/adaptation/ecap/MessageRep.cc 2011-02-03 13:29:48.000000000 -0500 @@ -48,6 +48,9 @@ Adaptation::Ecap::HeaderRep::add(const N HttpHeaderEntry *e = new HttpHeaderEntry(squidId, name.image().c_str(), value.toString().c_str()); theHeader.addEntry(e); + + if (squidId == HDR_CONTENT_LENGTH) + theMessage.content_length = theHeader.getInt64(HDR_CONTENT_LENGTH); } void @@ -58,6 +61,9 @@ Adaptation::Ecap::HeaderRep::removeAny(c theHeader.delByName(name.image().c_str()); else theHeader.delById(squidId); + + if (squidId == HDR_CONTENT_LENGTH) + theMessage.content_length = theHeader.getInt64(HDR_CONTENT_LENGTH); } libecap::Area Regards, Jonathan Wolfe On Feb 2, 2011, at 8:44 PM, Amos Jeffries wrote: > On Wed, 2 Feb 2011 20:09:05 -0800, Jonathan Wolfe wrote: >> Oops, here's the diff from Alex which I forgot to include below: >> >> === modified file 'src/adaptation/ecap/MessageRep.cc' >> --- src/adaptation/ecap/MessageRep.cc 2010-05-26 03:06:02 +0000 >> +++ src/adaptation/ecap/MessageRep.cc 2011-01-26 21:43:36 +0000 >> @@ -44,24 +44,30 @@ >> void >> Adaptation::Ecap::HeaderRep::add(const Name &name, const Value &value) >> { >> const http_hdr_type squidId = TranslateHeaderId(name); // HDR_OTHER > OK >> HttpHeaderEntry *e = new HttpHeaderEntry(squidId, >> name.image().c_str(), >> value.toString().c_str()); >> theHeader.addEntry(e); >> + >> + // XXX: this is too often and not enough, on many levels >> + theMessage.content_length = theHeader.getInt64(HDR_CONTENT_LENGTH); >> } >> >> void >> Adaptation::Ecap::HeaderRep::removeAny(const Name &name) >> { >> const http_hdr_type squidId = TranslateHeaderId(name); >> if (squidId == HDR_OTHER) >> theHeader.delByName(name.image().c_str()); >> else >> theHeader.delById(squidId); >> + >> + // XXX: this is too often and not enough, on many levels >> + theMessage.content_length = theHeader.getInt64(HDR_CONTENT_LENGTH); >> } >> >> libecap::Area >> Adaptation::Ecap::HeaderRep::image() const >> { >> MemBuf mb; >> mb.init(); >> >> >> This only works, I think, because when removing Content-Length we end up >> with a -1 in the length for the whole message, instead of the old (too >> large) content length. (There's a >> Adaptation::Ecap::XactionRep::setAdaptedBodySize function that's > commented >> out in the eCAP support, presumably because it's common to not know the >> length of the final adapted body, like in the gzip case.) > > > I think that patch should be: > > if (squidId == HDR_CONTENT_LENGTH) > theMessage.content_length = theHeader.getInt64(HDR_CONTENT_LENGTH); > > in both places to avoid that "too often" case. > >> >> There are a few options - assume the content-length for adapted messages >> is just the total object_len - hdr_sz, leave it always -1 unless the > eCAP >> module tells you otherwise by setting the Content-Length header maybe, > or >> finally, store it by accumulating the size of returned chunks along the > way >> receiving the adapted body and set it accordingly when there's no more >> adapted body to receive. > > We almost always end up with problems caused by large bodies extending > past any possible buffer window. So sending this headers after object > completion is not an available choice. > > AFAIK if the adaptor sends its reply with chunked encoding and no > Content-Length header at all it would work out. Squid should handle the > dechunking and connection termination requirements for old clients. > > Amos >