Bug 3448: 204 response problem in adaptation chains

When the first ICAP service in a chain respond with 204 the next service
is aborted on Must(old_request->canonical) expression inside Adaptation::Icap::ModXact::encapsulateHead method.

Squid ICAP try to set the request::canonical member of the adapted request
inside Adaptation::Icap::ModXact::prepEchoing when the 204 response received.
The adapted.header->parse(..) call some lines after will set canonical member
to NULL.

This patch calls the urlCanonical() function after parse() method
to build canonical member for the adapted request, instead of trying to copy
this member from the original request.

diff --git a/src/adaptation/icap/ModXact.cc b/src/adaptation/icap/ModXact.cc
index d769dd1cd80e692ef932bcf691656346626818ea..0451714b0f46036d18c03f5c4d86a660fe926874 100644 (file)
--- a/src/adaptation/icap/ModXact.cc
+++ b/src/adaptation/icap/ModXact.cc
@@ -945,10 +945,8 @@ void Adaptation::Icap::ModXact::prepEchoing()
     Must(!adapted.header);
     {
         HttpMsg::Pointer newHead;
-        if (const HttpRequest *oldR = dynamic_cast<const HttpRequest*>(oldHead)) {
+        if (dynamic_cast<const HttpRequest*>(oldHead)) {
             HttpRequest::Pointer newR(new HttpRequest);
-            newR->canonical = oldR->canonical ?
-                              xstrdup(oldR->canonical) : NULL; // parse() does not set it
             newHead = newR;
         } else if (dynamic_cast<const HttpReply*>(oldHead)) {
             newHead = new HttpReply;
@@ -965,6 +963,9 @@ void Adaptation::Icap::ModXact::prepEchoing()
 
     Must(adapted.header->parse(&httpBuf, true, &error));
 
+    if (HttpRequest *r = dynamic_cast<HttpRequest*>(adapted.header))
+        urlCanonical(r); // parse does not set HttpRequest::canonical
+
     Must(adapted.header->hdr_sz == httpBuf.contentSize()); // no leftovers
 
     httpBuf.clean();