<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    OK, <br>
    <br>
    I located my issue in
    Adaptation::Icap::ModXact::canBackupEverything() with the
    TheBackupLimit (64k)<br>
    <br>
    I tried to change the value of <span style="color:black;
      font-family:arial,sans-serif; font-size:10.0pt">SQUID_TCP_SO_RCVBUF
      by without success :-(<br>
      <br>
      This value is set with BodyPipe::MaxCapacity;<br>
    </span>How can I set this MaxCapacity ?<br>
    <br>
    Regards,<br>
    Gilles.<br>
    <br>
    <div class="moz-cite-prefix">Le 28/01/2016 17:46, Gilles Bardouillet
      a écrit :<br>
    </div>
    <blockquote cite="mid:56AA45F6.7070907@atos.net" type="cite">Sorry
      for the response form but I dont received the Alex email, so I
      tried below to recompose the thread discussion
      <br>
      <blockquote type="cite">On 01/25/2016 10:28 AM, Gilles Bardouillet
        wrote:
        <br>
        <br>
        >/I'm using SQUID with CAS ICAP Server but I have one issue :
        />//>/* for some images, squid receive icap error as
        ICAP_ERR_OTHER /
        <br>
        It may be useful to know more details about that ICAP error.
        What ICAP
        <br>
        response, if any, does Squid receive when it generates
        ICAP_ERR_OTHER?
        <br>
      </blockquote>
      Here is some details from debug mode :
      <br>
      <br>
      2015/12/09 11:32:11.786 kid3| 93,5| ModXact.cc(653) parseMore:
      have 182 bytes to parse [FD 32;Rr/w job924]
      <br>
      2015/12/09 11:32:11.786 kid3| 93,5| ModXact.cc(654) parseMore:
      <br>
      ICAP/1.0 200 OK
      <br>
      X-Apparent-Data-Types: JPG
      <br>
      Service: CAS 1.3.1.1(170722)
      <br>
      Service-ID: avscanner
      <br>
      ISTag: "56680096"
      <br>
      Encapsulated: req-body=0
      <br>
      Date: Wed, 09 Dec 2015 10:32:19 GMT
      <br>
      <br>
      <br>
      2015/12/09 11:32:11.786 kid3| 93,5| ModXact.cc(749) parseHeaders:
      parse ICAP headers
      <br>
      2015/12/09 11:32:11.786 kid3| 93,5| ModXact.cc(1079) parseHead:
      have 182 head bytes to parse; state: 0
      <br>
      2015/12/09 11:32:11.786 kid3| 93,5| ModXact.cc(1094) parseHead:
      parse success, consume 182 bytes, return true
      <br>
      2015/12/09 11:32:11.786 kid3| 93,3|
      ../../../src/base/AsyncJobCalls.h(177) dial:
      Adaptation::Icap::Xaction::noteCommRead threw exception: Invalid
      ICAP Response
      <br>
      2015/12/09 11:32:11.786 kid3| 93,4| Xaction.cc(514) setOutcome:
      ICAP_ERR_OTHER
      <br>
      <br>
      Do you need more ?
      <br>
      <blockquote type="cite">
        <br>
        <br>
        >/* I noticed that for all these errors, Squid dont send the
        HTTP header />/Allows 204 /
        <br>
        Allow:204 is not an HTTP header field. It is an ICAP header
        field.
        <br>
      </blockquote>
      Right
      <br>
      <blockquote type="cite">
        <br>
        <br>
        >/* I read the code and find the Allow 204 header _is only
        set when />/preview is enabled_. /
        <br>
        Are you sure? Several factors affect ICAP Allow:204 request
        header
        <br>
        presence. Preview availability should not be one of them because
        <br>
        Allow:204 is about 204 responses _outside_ of Preview. See RFC
        3507
        <br>
        Section 4.6.
        <br>
      </blockquote>
      Right, preview is only used for Allow 204 In and not Out
      <br>
      My case is about Allow 204 out.
      <br>
      <br>
      <br>
      here is the source code from 3.5.13 fromModXact.cc:
      <br>
      const bool allow204in = preview.enabled(); // TODO: add
      shouldAllow204in()
      <br>
      const bool allow204out = state.allowedPostview204 =
      shouldAllow204();
      <br>
      ....
      <br>
      else if (allow204out)
      <br>
          allowHeader = "Allow: 204\r\n";
      <br>
      <blockquote type="cite">
        <br>
        <br>
        >/My icap conf activated preview and preview size as follow :
        />/icap_preview_enable on />/icap_preview_size 1024 /
        <br>
        IIRC, Squid ignores icap_preview_size in squid.conf (a bug). The
        ICAP
        <br>
        service OPTIONS response determines the Preview size (subject to
        an
        <br>
        internal limit of 64KB).
        <br>
      </blockquote>
      My ICAP server (CAS) dont send any Preview size in OPTIONS
      response :-(
      <br>
      <blockquote type="cite">>/I read that the preview size value
        can be overwritten by OPTIONS />/requests, so can give me
        some details, hints in order to find why some />/pictures
        dont offer preview and then fails ? /
        <br>
        See RFC 3507 Section 4.5 for details on how Preview is
        negotiated. If
        <br>
        you think Squid violates the ICAP protocol, please file a bug
        report
        <br>
        with the corresponding capture of ICAP messages (from and to
        Squid).
        <br>
        <br>
        As for ICAP 204 outside of Preview, I believe Squid can offer to
        support
        <br>
        that ICAP response if all of the checks below are successful:
        <br>
        <br>
           * the origin server OPTIONS response includes Allow:204;
        <br>
           * the message content length is known at the ICAP request
        time; and
        <br>
           * the message content length does not exceed 64KB.
        <br>
      </blockquote>
      Thanks, I will check theses things.
      <br>
      <blockquote type="cite">If you prefer to analyze the code, see
        <br>
        Adaptation::Icap::ModXact::shouldAllow204() and
        <br>
        Adaptation::Icap::ModXact::canBackupEverything().
        <br>
        <br>
        <br>
        HTH,
        <br>
        <br>
        Alex.
        <br>
      </blockquote>
      Regards,
      <br>
      Gilles.
      <br>
    </blockquote>
  </body>
</html>