[squid-users] squid 5.7 FTP upload fails
Matus UHLAR - fantomas
uhlar at fantomas.sk
Tue Aug 13 13:53:55 UTC 2024
>>On 2024-08-09 09:03, Matus UHLAR - fantomas wrote:
>>>FTR, I sent the info privately, but we can continue
>>>discussing/solving it here.
>>
>>>maybeMakeSpaceAvailable: request buffer full: client_request_buffer_max_size=524288
>>>ReadNow: ... size 0, retval 0, errno 0
>>>terminateAll: 1/1 after ERR_CLIENT_GONE/WITH_CLIENT
>On 09.08.24 09:51, Alex Rousskov wrote:
>>AFAICT, you are suffering from a Squid bug that goes back to 2015
>>commit 4d1376d7 (that was fixing Squid bug 4206) or even earlier
>>code. Red flags were raised back in 2015, but nobody followed
>>through. We need to refactor
>>Server::maybeMakeSpaceAvailable()-related code to fix this bug.
>>
>>FWIW, we did similar work for Squid-to-peer communication in commit
>>cc8b26f9 and commit 50c5af88. Similar principles should apply to
>>client-Squid communication. Unfortunately, I do not have enough free
>>time to volunteer to fix this client-Squid bug now.
>>
>>At the expense of using more memory for some upload cases, you may
>>be able to work around the bug in some (but not all!) cases by
>>making client_request_buffer_max_size sufficiently large. For
>>example, setting client_request_buffer_max_size to 16 megabytes may
>>allow you to pass the test case you have privately shared.
On 12.08.24 11:27, Matus UHLAR - fantomas wrote:
>I have submitted bug 5405 so it's documented:
>
>https://bugs.squid-cache.org/show_bug.cgi?id=5405
Does this bug apply for POST requests as well?
Because the biggest PUT is about 4MB so far, but I've seen POST requests
nearly 54MB big.
--
Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0...
More information about the squid-users
mailing list