i) Retry seems to fetch one chunk of the response and not the complete.
ii) Enabling sslbump and turning ICAP off, not helping.
iii) gcc version is 7.3.1 (Red Hat 7.3.1-17)
Also want to point out that, squid connects to another non-squid proxy to reach internet.
cache_peer <proxy_url> parent <port> 0 no-query default
On Tuesday, January 9, 2024 at 02:18:14 PM EST, Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
On 2024-01-09 11:51, Zhang, Jinshu wrote:
> Client got below response headers and body. Masked few details.
Thank you.
> Retry seems to fetch data remaining.
I would expect a successful retry to fetch the entire response, not just
the remaining bytes, but perhaps that is what you meant. Thank you for
sharing this info.
> Want to point out that removing sslbump everything is working fine,
> but we wanted to keep it for ICAP scanning.
What if you keep SslBump enabled but disable any ICAP analysis
("icap_enable off")? This test may tell us if the problem is between
Squid and the origin server or Squid and the ICAP service...
> We tried compiling 6.x in Amazon linux, using latest gcc, but facing similar error - https://lists.squid-cache.org/pipermail/squid-users/2023-July/026016.html
What is the "latest gcc" version in your environment? I suspect it is
not the latest GCC version available to folks running Amazon Linux, but
you may need to install some packages to get a more recent GCC version.
Unfortunately, I cannot give specific instructions for Amazon Linux
right now.
HTH,
Alex.
> HTTP/1.1 200 OK
> Date: Tue, 09 Jan 2024 15:41:33 GMT
> Server: Apache/mod_perl/2.0.10 Perl
> Content-Type: application/download
> X-Cache: MISS from ip-x-y-z
> Transfer-Encoding: chunked
> Via: xxx (ICAP)
> Connection: keep-alive
>
> 1000
> File-Id: xyz.zip
> Local-Path: x/y/z.txt
> Content-Size: 2967
> < binary content >
>
>
> Access log(1st attempt):
> 1704814893.695 138 x.y.0.2 NONE_NONE/200 0 CONNECT a.b.com:443 - FIRSTUP_PARENT/10.x.y.z -
> 1704814900.491 6779 172.17.0.2 TCP_MISS/200 138996535 POST https://a.b.com/xyz - FIRSTUP_PARENT/10.x.y.z application/download
>
> Retry after 5 mins:
> 1704815201.530 189 x.y.0.2 NONE_NONE/200 0 CONNECT a.b.com:443 - FIRSTUP_PARENT/10.x.y.z -
> 1704815208.438 6896 x.y.0.2 TCP_MISS/200 138967930 POST https://a.b.com/xyz - FIRSTUP_PARENT/10.x.y.z application/download
>
> Jinshu Zhang
>
>
> Fannie Mae Confidential
> -----Original Message-----
> From: squid-users <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of Alex Rousskov
> Sent: Tuesday, January 9, 2024 9:53 AM
> Subject: [EXTERNAL] Re: chunked transfer over sslbump
>
>
> On 2024-01-09 09:13, Arun Kumar wrote:
>
>> I have compiled/installed squid v5.8 in Amazon Linux and configured it
>> with sslbump option. Squid is used as proxy to get response from https
>> site. When the https site sends chunked response, it appears that the
>> first response comes but it get stuck and doesn't receive the full
>> response. Appreciate any help.
> There were some recent chunking-related changes in Squid, but none of them is likely to be responsible for the problems you are describing unless the origin server response is very special/unusual.
>
> Does the client in this test get the HTTP response header? Some HTTP response body bytes?
>
> To triage the problem, I recommend sharing the corresponding access.log records (at least). Seeing debugging of the problematic transaction may be very useful (but avoid using production security keys and other sensitive information in such tests):
>
> Please note that Squid v5 is not officially supported and has more known security vulnerabilities than Squid v6. You should be using Squid v6.
>
>
> HTH,
>
> Alex.
>
> _______________________________________________
> squid-users mailing list
>
> _______________________________________________
> squid-users mailing list
_______________________________________________
squid-users mailing list
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx https://lists.squid-cache.org/listinfo/squid-users
