Hi Alex,
I fixed a bug in the go-icap/icap library, seen here:
Here you can see squid issuing a RESPMOD to my ICAP server with a Preview of “0”, but it does contain a HTTP response. And since my ICAP service will not return a HTTP response since the Preview size is 0, my http client receives nothing from squid. I checked but I don’t think I see a 100 continuation from ICAP in the dump anymore.
(I’ve revoked my session cookies for this dump)
One step at a time closer to the truth! :-)
Regards, On 3/6/21 5:09 AM, Niels Hofmans wrote:I’ve uploaded a tcpdump sample of where I’m requesting an image through
squid + icap and where you can see the image response being posted fully
to the ICAP service.
AFAICT, all ICAP REQMOD and RESPMOD requests in your packet capture sendzero-size Preview containing just the HTTP headers (e.g., see frame#44). In one case, Squid also sends the HTTP response body but onlybecause your ICAP service explicitly requests that HTTP response body byresponding to Squid Preview with ICAP 100 Continue control message(e.g., see frame #48)!If your ICAP service does not want to see an HTTP body, then it shouldnot ask for it. It should respond (usually with ICAP 200 or ICAP 204)based on the Preview alone, without sending ICAP 100 Continue controlmessage first.HTH,Alex.On 5 Mar 2021, at 23:32, Alex Rousskov wrote:
On 3/5/21 5:21 PM, Niels Hofmans wrote:
I receive that large payload right after an OPTIONS call to my ICAP
endpoint. It is the preview.
The timing of an ICAP request does not determine whether that request
has a Preview stage and whether the "unexpected" body bytes were sent
during that Preview stage. I am asking these questions because I want to
determine whether Squid increases Preview size beyond what your server
has requested or does not send Preview at all.
Please share the ICAP headers of the problematic REQMOD request and the
last chunk metadata of that request body. You can get the latter from a
packet capture if your ICAP server does not report it in a convenient
form. In fact, sharing (a pointer to) the packet capture of the whole
problematic ICAP request is probably a good idea!
Alex.
On 5 Mar 2021, at 17:21, Alex Rousskov wrote:
On 3/5/21 2:55 AM, Niels Hofmans wrote:
One more: I believe ICAP is not respecting the Preview header for REQMOD
nor RESPMOD.
For the REQMOD OPTIONS requests, I respond with:
ICAP/1.0 200 OK
Allow: 200,204
Connection: close
Date: Fri, 05 Mar 2021 07:34:56 GMT
Encapsulated: null-body=0
Methods: REQMOD
Preview: 64000
However in my ICAP service, I often receive a request body over 64000
bytes, e.g. 1000000 request bytes.
Receive when? During preview, instead of Preview, and/or after Preview?
I also noticed that a "Preview: 0” will not have any effect and the ICAP
service will still receive a complete HTTP REQMOD+REQRESP body.
Receive when? During preview, instead of Preview, and/or after Preview?
Alex.
icap_enable on
icap_connect_timeout 1 second
icap_service_failure_limit -1
icap_send_client_ip on
icap_preview_size 0
icap_persistent_connections on
icap_service service_req reqmod_precache bypass=0
icap://172.17.0.2:1344/request <icap://172.17.0.2:1344/request>
<icap://172.17.0.2:1344/request <icap://172.17.0.2:1344/request>>
icap_service service_res respmod_precache bypass=0
icap://172.17.0.2:1344/response <icap://172.17.0.2:1344/response>
<icap://172.17.0.2:1344/response <icap://172.17.0.2:1344/response>>
icap_preview_enable on
adaptation_access service_req allow all
adaptation_access service_res allow all
|
