[squid-users] chunked transfer over sslbump
Hello Squid Community, 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. Thanks.___ squid-users mailing list squid-users@lists.squid-cache.org https://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] chunked transfer over sslbump
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 parent 0 no-query default
On Tuesday, January 9, 2024 at 02:18:14 PM EST, Alex Rousskov
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 On Behalf Of
> Alex Rousskov
> Sent: Tuesday, January 9, 2024 9:53 AM
> To: squid-users@lists.squid-cache.org
> Subject: [EXTERNAL] Re: [squid-users] 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):
> https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction
>
> 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@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] chunked transfer over sslbump
On Wednesday, January 10, 2024 at 11:09:48 AM EST, Alex Rousskov
wrote:
On 2024-01-10 09:21, Arun Kumar wrote:
>> 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)
>GCC v7 has insufficient C++17 support. I recommend installing GCC v9 or
better and then trying with Squid v6.6 or newer.
Arun: Compiled Squid 6.6 with gcc 11.4 and still seeing the same issue.
> FWIW, if the problem persists in Squid v6, sharing debugging logs would
be the next recommended step.
Arun: debug_options ALL,6 giving too much log. Any particular option we can use
to debug this issue?
>HTH,
>Alex.
> Also want to point out that, squid connects to another non-squid proxy
> to reach internet.
> /cache_peer parent 0 no-query default/
>
> On Tuesday, January 9, 2024 at 02:18:14 PM EST, Alex Rousskov 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
> <[squid-users] compile error in squid v6.1>
>
> 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 <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 <https://a.b.com/xyz> - FIRSTUP_PARENT/10.x.y.z
> application/download
> >
> > Jinshu Zhang
> >
> >
> > Fannie Mae Confidential
> > -Original Message-
> > From: squid-users <mailto:squid-users-boun...@lists.squid-cache.org>> On Behalf Of Alex
> Rousskov
> > Sent: Tuesday, January 9, 2024 9:53 AM
> > To: squid-users@lists.squid-cache.org
> <mailto:squid-users@lists.squid-cache.org>
> > Subject: [EXTERNAL] Re: [squid-users] 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
>
Re: [squid-users] chunked transfer over sslbump
Sorry, due to organization policy not possible to upload the debug logs.
Anything to look specifically in the debug logs?Also please suggest if we can
tweak the below sslbump configuration, to make the chunked transfer work
seamless.
http_port tcpkeepalive=60,30,3 ssl-bump generate-host-certificates=on
dynamic_cert_mem_cache_size=20MB tls-cert= tls-key=
cipher=... options=NO_TLSv1,... tls_dh=prime256v1:
ssl_bump stare all
PS: Any documentations/video available to understand the bump/stare/peek/splice
better? Not understanding much from the squid-cache.org contents.
On Friday, January 12, 2024 at 02:10:40 PM EST, Alex Rousskov
wrote:
On 2024-01-12 09:21, Arun Kumar wrote:
> On Wednesday, January 10, 2024 at 11:09:48 AM EST, Alex Rousskov wrote:
>
>
> On 2024-01-10 09:21, Arun Kumar wrote:
> >> 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)
>
> >GCC v7 has insufficient C++17 support. I recommend installing GCC v9 or
> better and then trying with Squid v6.6 or newer.
>
> Arun: Compiled Squid 6.6 with gcc 11.4 and still seeing the same issue.
Glad you were able to upgrade to Squid v6.6!
> > FWIW, if the problem persists in Squid v6, sharing debugging logs would
> be the next recommended step.
>
> Arun: /debug_options ALL,6 /giving too much log. Any particular option
> we can use to debug this issue?
Please share[^1] a pointer to compressed ALL,9 cache.log collected while
reproducing the problem with Squid v6.6:
https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction
Debugging logs are for developers. Developers can deal with large
volumes of debugging information. You can use services like DropBox to
share large compressed logs. Said that, the better you can isolate the
problem/traffic, the higher are the chances that a developer will (have
the time to) find the answer to your question in the noisy log.
[^1]: Please feel free to share privately if needed, especially if you
are using sensitive configuration or transactions.
Alex.
> > Also want to point out that, squid connects to another non-squid proxy
> > to reach internet.
> > cache_peer parent 0 no-query default
> >
> > On Tuesday, January 9, 2024 at 02:18:14 PM EST, Alex Rousskov 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
> <https://lists.squid-cache.org/pipermail/squid-users/2023-July/026016.html>
> <[squid-users] compile error in squid v6.1
> <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
Re: [squid-users] chunked transfer over sslbump
Appreciate if you can provide any insights.
Sent from Yahoo Mail for iPhone
On Friday, January 19, 2024, 9:08 AM, Arun Kumar wrote:
Sorry, due to organization policy not possible to upload the debug logs.
Anything to look specifically in the debug logs?Also please suggest if we can
tweak the below sslbump configuration, to make the chunked transfer work
seamless.
http_port tcpkeepalive=60,30,3 ssl-bump generate-host-certificates=on
dynamic_cert_mem_cache_size=20MB tls-cert= tls-key=
cipher=... options=NO_TLSv1,... tls_dh=prime256v1:
ssl_bump stare all
PS: Any documentations/video available to understand the bump/stare/peek/splice
better? Not understanding much from the squid-cache.org contents.
On Friday, January 12, 2024 at 02:10:40 PM EST, Alex Rousskov
wrote:
On 2024-01-12 09:21, Arun Kumar wrote:
> On Wednesday, January 10, 2024 at 11:09:48 AM EST, Alex Rousskov wrote:
>
>
> On 2024-01-10 09:21, Arun Kumar wrote:
> >> 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)
>
> >GCC v7 has insufficient C++17 support. I recommend installing GCC v9 or
> better and then trying with Squid v6.6 or newer.
>
> Arun: Compiled Squid 6.6 with gcc 11.4 and still seeing the same issue.
Glad you were able to upgrade to Squid v6.6!
> > FWIW, if the problem persists in Squid v6, sharing debugging logs would
> be the next recommended step.
>
> Arun: /debug_options ALL,6 /giving too much log. Any particular option
> we can use to debug this issue?
Please share[^1] a pointer to compressed ALL,9 cache.log collected while
reproducing the problem with Squid v6.6:
https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction
Debugging logs are for developers. Developers can deal with large
volumes of debugging information. You can use services like DropBox to
share large compressed logs. Said that, the better you can isolate the
problem/traffic, the higher are the chances that a developer will (have
the time to) find the answer to your question in the noisy log.
[^1]: Please feel free to share privately if needed, especially if you
are using sensitive configuration or transactions.
Alex.
> > Also want to point out that, squid connects to another non-squid proxy
> > to reach internet.
> > cache_peer parent 0 no-query default
> >
> > On Tuesday, January 9, 2024 at 02:18:14 PM EST, Alex Rousskov 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
> <https://lists.squid-cache.org/pipermail/squid-users/2023-July/026016.html>
> <[squid-users] compile error in squid v6.1
> <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 >
> &
[squid-users] Any Python ICAP server available
The ICAP-Server(Python) mentioned in this page, seems to be very old. Any other squid compatible ICAP server available?___ squid-users mailing list squid-users@lists.squid-cache.org https://lists.squid-cache.org/listinfo/squid-users
[squid-users] Error during ICAP RESPMOD
Any idea, the reason for error in ModXact.cc parsePart fuction.Happening during parsing the response from ICAP parsePart: have 144 head bytes to parse; state: 0parsePart: head parsing result: 0 detail: 600 ___ squid-users mailing list squid-users@lists.squid-cache.org https://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Error during ICAP RESPMOD
The lines above are. The content-length is 138 (8a in hex), but the bytes are
144. Could this be the reason?
parseMore: have 144 bytes to parse [FD 14;RBG/Comm(14)wr job24]parseMore:
8a^M{"activity":"Make a simple musical
instrument","type":"music","participants":1,"price:0.4,"link":"","key":"7091374","accessibility":0.25}^MparseHeaders:
parse ICAP headersparsePart: have 144 head bytes to parse; state: 0
parsePart: head parsing result: 0 detail: 600
On Monday, March 18, 2024 at 11:21:02 PM EDT, Alex Rousskov
wrote:
On 2024-03-18 18:46, Arun Kumar wrote:
> Any idea, the reason for error in ModXact.cc parsePart fuction.
> Happening during parsing the response from ICAP
>
>
> parsePart: have 144 head bytes to parse; state: 0
> parsePart: head parsing result: 0 detail: 600
AFAICT, Squid considers received ICAP response header malformed. More
than five possible problems/cases may match the above lines. The answer
to your question (or an additional clue!) is in different debugging
output, possibly logged somewhere between the two lines quoted above.
The right debugging lines may be visible in "debug_options ALL,2 58,5,
93,5" output, but it is usually best to share compressed ALL,9 logs
(privately if needed).
https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction
Sharing the problematic ICAP response (header) in a raw packet capture
format (to preserve important details) may also be very useful.
HTH,
Alex.
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Error during ICAP RESPMOD
I managed to reproduce the problem in my personal setup. Please find the cache
logs when the problem is reproduced. Squid version is 5.8
cache.zip
| |
cache.zip
|
On Friday, March 22, 2024 at 11:02:51 PM EDT, Alex Rousskov
wrote:
On 2024-03-22 13:11, Arun Kumar wrote:
> The lines above are. The content-length is 138 (8a in hex), but the
> bytes are 144. Could this be the reason?
>
> parseMore: have 144 bytes to parse [FD 14;RBG/Comm(14)wr job24]
> parseMore:
> 8a^M
> {"activity":"Make a simple musical
> instrument","type":"music","participants":1,"price:0.4,"link":"","key":"7091374","accessibility":0.25}^M
> parseHeaders: parse ICAP headers
> parsePart: have 144 head bytes to parse; state: 0
> parsePart: head parsing result: 0 detail: 600
I cannot be sure based on the tiny snippets shared so far, but it
_looks_ like Squid expected an ICAP response header and got an ICAP
response body chunk instead. It is also possible that we are looking at
log lines from two unrelated ICAP transactions, or I am simply
misinterpreting the snippets.
If you want a more reliable diagnosis, then my earlier recommendation
regarding sharing (privately if needed) the following information still
stands:
* compressed ALL,9 cache.log and
* the problematic ICAP response in a raw packet capture format.
HTH,
Alex.
> On Monday, March 18, 2024 at 11:21:02 PM EDT, Alex Rousskov
> wrote:
>
>
> On 2024-03-18 18:46, Arun Kumar wrote:
>
> > Any idea, the reason for error in ModXact.cc parsePart fuction.
> > Happening during parsing the response from ICAP
> >
> >
> > parsePart: have 144 head bytes to parse; state: 0
> > parsePart: head parsing result: 0 detail: 600
>
>
> AFAICT, Squid considers received ICAP response header malformed. More
> than five possible problems/cases may match the above lines. The answer
> to your question (or an additional clue!) is in different debugging
> output, possibly logged somewhere between the two lines quoted above.
> The right debugging lines may be visible in "debug_options ALL,2 58,5,
> 93,5" output, but it is usually best to share compressed ALL,9 logs
> (privately if needed).
>
> https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction
>
> <https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction>
>
>
> Sharing the problematic ICAP response (header) in a raw packet capture
> format (to preserve important details) may also be very useful.
>
>
> HTH,
>
> Alex.
>
>
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Error during ICAP RESPMOD
I managed to reproduce the problem in my personal setup. Please find the cache
logs when the problem is reproduced. Squid version is 5.8
https://drive.google.com/file/d/19yirXfxKli7NXon4ewiy-v3GpLvECT1i/view?usp=sharing
On Wednesday, April 24, 2024 at 09:16:23 PM EDT, Arun Kumar
wrote:
I managed to reproduce the problem in my personal setup. Please find the
cache logs when the problem is reproduced. Squid version is 5.8
cache.zip
| |
cache.zip
|
|
|
| |
cache.zip
|
|
|
On Friday, March 22, 2024 at 11:02:51 PM EDT, Alex Rousskov
wrote:
On 2024-03-22 13:11, Arun Kumar wrote:
> The lines above are. The content-length is 138 (8a in hex), but the
> bytes are 144. Could this be the reason?
>
> parseMore: have 144 bytes to parse [FD 14;RBG/Comm(14)wr job24]
> parseMore:
> 8a^M
> {"activity":"Make a simple musical
> instrument","type":"music","participants":1,"price:0.4,"link":"","key":"7091374","accessibility":0.25}^M
> parseHeaders: parse ICAP headers
> parsePart: have 144 head bytes to parse; state: 0
> parsePart: head parsing result: 0 detail: 600
I cannot be sure based on the tiny snippets shared so far, but it
_looks_ like Squid expected an ICAP response header and got an ICAP
response body chunk instead. It is also possible that we are looking at
log lines from two unrelated ICAP transactions, or I am simply
misinterpreting the snippets.
If you want a more reliable diagnosis, then my earlier recommendation
regarding sharing (privately if needed) the following information still
stands:
* compressed ALL,9 cache.log and
* the problematic ICAP response in a raw packet capture format.
HTH,
Alex.
> On Monday, March 18, 2024 at 11:21:02 PM EDT, Alex Rousskov
> wrote:
>
>
> On 2024-03-18 18:46, Arun Kumar wrote:
>
> > Any idea, the reason for error in ModXact.cc parsePart fuction.
> > Happening during parsing the response from ICAP
> >
> >
> > parsePart: have 144 head bytes to parse; state: 0
> > parsePart: head parsing result: 0 detail: 600
>
>
> AFAICT, Squid considers received ICAP response header malformed. More
> than five possible problems/cases may match the above lines. The answer
> to your question (or an additional clue!) is in different debugging
> output, possibly logged somewhere between the two lines quoted above.
> The right debugging lines may be visible in "debug_options ALL,2 58,5,
> 93,5" output, but it is usually best to share compressed ALL,9 logs
> (privately if needed).
>
> https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction
>
> <https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction>
>
>
> Sharing the problematic ICAP response (header) in a raw packet capture
> format (to preserve important details) may also be very useful.
>
>
> HTH,
>
> Alex.
>
>
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users
[squid-users] Error from icap during respmod
Configured python based icap server (pyicap) and getting 500 Internal Server error during respmod.https://drive.google.com/file/d/19yirXfxKli7NXon4ewiy-v3GpLvECT1i/view?usp=sharing Squid configuration:icap_enable onicap_send_client_ip onicap_send_client_username onicap_client_username_encode officap_client_username_header X-Authenticated-Usericap_preview_enable onicap_preview_size 1024 icap_service service_req reqmod_precache bypass=0 icap://127.0.0.1:13440/exampleicap_service service_resp respmod_precache bypass=0 icap://127.0.0.1:13441/example ___ squid-users mailing list squid-users@lists.squid-cache.org https://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Error from icap during respmod
Thank you very much for the response. Are you aware of any compatible Python
or Java based iCAP server implemenation? We want to implement custom virus
scanning of the response. I got the book Squid: The Definitive Guide and going
over for more understanding. Saw your name mentioned by the author. I am very
proud to work with great people like you.
On Thursday, May 2, 2024 at 04:18:45 PM EDT, Alex Rousskov
wrote:
On 2024-04-29 13:06, Arun Kumar wrote:
> Configured python based icap server (pyicap) and getting 500 Internal
> Server error during respmod.
AFAICT, this ICAP RESPMOD service is buggy: It sends what looks like an
HTTP response body chunk after sending an ICAP 100 Continue control
message. Instead, it is supposed to send the final ICAP response headers
and HTTP response headers _before_ sending that HTTP response body chunk.
00:50:54.989 ... ReadNow: conn33 ... size 65535, retval 25
ICAP/1.0 100 Continue
00:50:54.991 ReadNow: conn33 ... size 65535, retval 137
83
{"activity":...}
HTH,
Alex.
> https://drive.google.com/file/d/19yirXfxKli7NXon4ewiy-v3GpLvECT1i/view?usp=sharing
>
> <https://drive.google.com/file/d/19yirXfxKli7NXon4ewiy-v3GpLvECT1i/view?usp=sharing>
>
> Squid configuration:
> icap_enable on
> icap_send_client_ip on
> icap_send_client_username on
> icap_client_username_encode off
> icap_client_username_header X-Authenticated-User
> icap_preview_enable on
> icap_preview_size 1024
>
> icap_service service_req reqmod_precache bypass=0
> icap://127.0.0.1:13440/example
> icap_service service_resp respmod_precache bypass=0
> icap://127.0.0.1:13441/example
>
>
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users
