[squid-users] Problem caching range requests with range_offset_limit

[Alex Rousskov]

On 8/10/22 22:43, osy wrote:
> I am trying to cache Azure objects. I have SSL bump and the following config:
> 
> maximum_object_size 1000 MB
> acl azure_storage dstdomain .blob.core.windows.net
> range_offset_limit -1 azure_storage
> 
> My expectation is that when a request is made with the Range header,
> that Squid will request the object starting from the beginning, return
> the data when it reaches the range, then keep the connection open and
> keep requesting data until the end.

N.B. In the above "keep the connection" should refer to the 
Squid-to-origin connection, not the user_agent-to-Squid connection.


> However, I observe the last part
> isn't true: the connection to the server is closed after the proxy
> client closes the connection.
> 
> 2022/08/10 18:55:23.152| 5,3| Read.cc(92) ReadNow:
> local=127.0.0.1:3128 remote=127.0.0.1:57075 FD 21 flags=1, size 3644,
> retval 0, errno 0
> 2022/08/10 18:55:23.152| 33,5| Server.cc(147) doClientRead:
> local=127.0.0.1:3128 remote=127.0.0.1:57075 FD 21 flags=1 closed?
> 2022/08/10 18:55:23.152| 33,3| client_side.cc(1418)
> connFinishedWithConn: local=127.0.0.1:3128 remote=127.0.0.1:57075 FD
> 21 flags=1 aborted (half_closed_clients disabled)
> 2022/08/10 18:55:23.152| 33,3| Pipeline.cc(56) terminateAll: Pipeline
> 0x149704e80 notify(0) 0x13a817600*3
> 2022/08/10 18:55:23.152| 90,3| store_client.cc(651) storeUnregister:
> storeUnregister: called for 'F43F6204305C4808C2A393C7CC905C16'
> 2022/08/10 18:55:23.153| 90,3| store_client.cc(764)
> CheckQuickAbortIsReasonable: entry=e:d5 at 0=w1p2V/0x6000038f6d80*6
> 2022/08/10 18:55:23.153| 90,3| store_client.cc(755)
> storePendingNClients: storePendingNClients: returning 0
> 2022/08/10 18:55:23.153| 90,3| store_client.cc(788)
> CheckQuickAbortIsReasonable: mem=0x14a14bcb0
> 2022/08/10 18:55:23.153| 90,3| store_client.cc(817)
> CheckQuickAbortIsReasonable: quick-abort? NO admin configured range
> replies to full-download
> 2022/08/10 18:55:23.153| 33,3| Pipeline.cc(69) popMe: Pipeline
> 0x149704e80 drop 0x13a817600*3
> 2022/08/10 18:55:23.153| 33,3| client_side_request.cc(270)
> ~ClientHttpRequest: httpRequestFree: [url here]

Just to avoid any misunderstanding, the above debugging quote does _not_ 
show the connection to the origin server being closed. There are many 
things called "servers" and "clients" in this context. The "Server.cc" 
above is a Squid task parsing requests from user agents and responding 
with a replies. It is nearly unrelated to the origin server.

The above trace does not necessarily contradict your configuration and 
expectations AFAICT. It shows that the user agent closed the connection 
to Squid, but Squid may have decided to keep going with downloading the 
response from the origin server ("quick-abort? NO"). Something else 
could have gone wrong with that download later (or even earlier), of 
course, but the trace does not show that AFAICT.


HTH,

Alex.



> I also tried setting "half_closed_clients on" but that just defers the
> error to a write later on. Any advice would be appreciated, thanks!
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users