[squid-users] mangle ranges using ICAP

[Alfredo Rezinovsky]

On 05/12/16 00:29, Alex Rousskov wrote:
> On 12/04/2016 03:05 PM, Alfredo Rezinovsky wrote:
>> Let say a client asks for a URL using a range: 0-256000.
>>
>> I want squid to ask just for 10.000 bytes and answer as if the request
>> was server side aborted.
>>
>> I can change the request Range: "bytes=0-256000" to "bytes=0-10000" with
>> and icap server
>>
>>
>> In the answer I'm trying to change the Content-Range from
>> "0-10000/total" to "0-256000/total" and Content-Length from "10001" to
>> "256001" squid won't hung up and the client will stay waiting after the
>> first 10001 bytes.
>>
>> There's a way to make squid send what it gets from the icap and then
>> drop the TCP connection as in a server side aborted connection?
> I have not tested it, but I would expect Squid to close the TCP
> connection to the HTTP client if the ICAP service aborts the
> corresponding RESPMOD transaction (i.e., closes the ICAP connection
> before serving the entire ICAP response).
I noticed that after sending the mail.
I tried to icap encapsule an aborted http connection and squid (and the 
client) stays waiting.
I will try to encapsule icap as if the http connection is complete and 
then abort the icap conection to see what happens.

Thanks.

> In theory, Squid should read the embedded HTTP response headers and
> expect 256001 HTTP body bytes. Your ICAP service can close the
> connection after sending fewer HTTP body bytes to simulate the abort.
> Such premature aborts do happen in virus filtering with data trickling
> environments, so I would expect the corresponding Squid code to work in
> principle.
>
> In practice, Squid might get confused with ICAP service manipulations of
> the overall transaction state. You would need to test this to know
> whether your specific plan works without any Squid modifications.
>
> For example, there is a bug report about Squid getting confused when an
> ICAP REQMOD service rewrites a CONNECT request to a GET request (or vice
> versa, I do not recall). You might hit somewhat similar limitations with
> range manipulations.
>
>
> HTH,
>
> Alex.
>