RE: [squid-users] FW: Problems with POST upload of file

Hi,

I increased debugging and found a Broken pipe in cache.log.
 
See below: commHandleWrite: FD 20: write failure: (32) Broken pipe.

This seeems to an internal squid problem. I have discovered this on a Solaris 8, but
basically the same config running on Linux seems to work .

/Anders

2001/11/08 12:22:53| storeClientCopy: FAFD679D36A3EE87A7F5A5069AC26A29, seen 63184, want 63184, size 4096, cb 5bf78, cbdata 4335c8
2001/11/08 12:22:53| cbdataLock: 433d38
2001/11/08 12:22:53| storeClientCopy2: FAFD679D36A3EE87A7F5A5069AC26A29
2001/11/08 12:22:53| storeClientCopy2: Waiting for more
2001/11/08 12:22:53| cbdataUnlock: 433d38
2001/11/08 12:22:53| cbdataUnlock: 4335c8
2001/11/08 12:22:53| InvokeHandlers: FAFD679D36A3EE87A7F5A5069AC26A29
2001/11/08 12:22:53| InvokeHandlers: checking client #0
2001/11/08 12:22:53| cbdataLock: 433d38
2001/11/08 12:22:53| storeClientCopy2: FAFD679D36A3EE87A7F5A5069AC26A29
2001/11/08 12:22:53| storeClientCopy2: Copying from memory
2001/11/08 12:22:53| cbdataLock: 4335c8
2001/11/08 12:22:53| cbdataUnlock: 433d38
2001/11/08 12:22:53| InvokeHandlers: FAFD679D36A3EE87A7F5A5069AC26A29
2001/11/08 12:22:53| InvokeHandlers: checking client #0
2001/11/08 12:22:53| InvokeHandlers: FAFD679D36A3EE87A7F5A5069AC26A29
2001/11/08 12:22:53| InvokeHandlers: checking client #0
2001/11/08 12:22:53| InvokeHandlers: FAFD679D36A3EE87A7F5A5069AC26A29
2001/11/08 12:22:53| InvokeHandlers: checking client #0
2001/11/08 12:22:53| InvokeHandlers: FAFD679D36A3EE87A7F5A5069AC26A29
2001/11/08 12:22:53| InvokeHandlers: checking client #0
2001/11/08 12:22:53| InvokeHandlers: FAFD679D36A3EE87A7F5A5069AC26A29
2001/11/08 12:22:53| InvokeHandlers: checking client #0
2001/11/08 12:22:53| storeMaintainSwapSpace: f=0.000000, max_scan=100, max_remove=10
2001/11/08 12:22:53| storeMaintainSwapSpace: scanned 100/10s
2001/11/08 12:22:54| 100 were scanned
2001/11/08 12:22:54| 0 were locked
2001/11/08 12:22:54| 0 were expired
2001/11/08 12:22:55| commHandleWrite: FD 20: write failure: (32) Broken pipe.
2001/11/08 12:22:55| cbdataValid: 4335c8
2001/11/08 12:22:55| cbdataLock: 4335c8
2001/11/08 12:22:55| pumpClose: 4335c8 Server FD 20, Client FD 14
2001/11/08 12:22:55| storeUnregister: called for 'FAFD679D36A3EE87A7F5A5069AC26A29'
2001/11/08 12:22:55| cbdataUnlock: 4335c8
2001/11/08 12:22:55| cbdataFree: 433d38
2001/11/08 12:22:55| cbdataReallyFree: Freeing 433d38
2001/11/08 12:22:55| storePendingNClients: returning 0
2001/11/08 12:22:55| CheckQuickAbort2: entry=433600, mem=433640
2001/11/08 12:22:55| CheckQuickAbort2: YES KEY_PRIVATE
2001/11/08 12:22:55| storeLockObject: key 'FAFD679D36A3EE87A7F5A5069AC26A29' count=2
2001/11/08 12:22:55| InvokeHandlers: FAFD679D36A3EE87A7F5A5069AC26A29
2001/11/08 12:22:55| storeUnlockObject: key 'FAFD679D36A3EE87A7F5A5069AC26A29' count=1
2001/11/08 12:22:55| fwdFail: ERR2:55| cbdataValid: 434f58
2001/11/08 12:22:55| fwdServerClosed: FD 20 http://www.abc.com:10085/cgi-bin/some.cgi
2001/11/08 12:22:55| pumpRestart: NO: mem->inmem_lo == 63184
2001/11/08 12:22:55| fwdStateFree: 434f58
2001/11/08 12:22:55| storeLockObject: key '55203275B8BC051889393EF3613091B4' count=4
2001/11/08 12:22:55| errorConvert: %U --> '[no URL]'
2001/11/08 12:22:55| errorConvert: %U --> '[no URL]'
2001/11/08 12:22:55| errorConvert: %E --> '[No Error]'
2001/11/08 12:22:55| errorConvert: %w --> 'cachemgr@abc.com'
2001/11/08 12:22:55| errorConvert: %w --> 'cachemgr@abc.com'
2001/11/08 12:22:55| errorConvert: %T --> 'Thu, 08 Nov 2001 11:22:55 GMT'
2001/11/08 12:22:55| errorConvert: %h --> 'proxy.abc.com'
2001/11/08 12:22:55| errorConvert: %s --> 'Squid/2.3.STABLE4'
2001/11/08 12:22:55| errorConvert: %S --> '
<br clear="all">
<hr noshade size=1>
Generated Thu, 08 Nov 2001 11:22:55 GMT by proxy.abc.com (Squid/2.3.STABLE4)
</BODY></HTML>
'
2001/11/08 12:22:55| InvokeHand11/08 12:22:55| storeEntryValidLength: Checking '55203275B8BC051889393EF3613091B4'
2001/11/08 12:22:55| InvokeHandlers: 55203275B8BC051889393EF3613091B4
2001/11/08 12:22:55| InvokeHandlers: checking client #0
2001/11/08 12:22:55| storeUnlockObject: key '55203275B8BC051889393EF3613091B4' count=3
2001/11/08 12:22:55| storePendingNClients: returning 1
2001/11/08 12:22:55| storeUnlockObject: key '55203275B8BC051889393EF3613091B4' count=2
2001/11/08 12:22:55| cbdataFree: 434f58
2001/11/08 12:22:55| cbdataFree: 434f58 has 1 locks, not freeing
2001/11/08 12:22:55| cbdataUnlock: 434f58
2001/11/08 12:22:55| cbdataReallyFree: Freeing 434f58
2001/11/08 12:22:55| fd_close FD 20 http://www.abc.com:10085/cgi-bin/some.cgi
2001/11/08 12:22:55| cbdataValid: 42da78
--More--(99%)

-----Original Message-----
From: Anders Strandberg (EPL) [mailto:Anders.Strandberg@epl.ericsson.se]
Sent: den 7 november 2001 14:11
To: 'squid-users@squid-cache.org'
Subject: [squid-users] FW: Problems with POST upload of file

Hi,

We are running a squid 2.3.stable4 on Solaris 8. The problem is that file uploads to a corporate site does not seem to work correctly. Files are being partly uploaded (different results from time to time) and the clients are "Terminated abnormally (IE) or "Connection aborted" (NS) . All traffic should run through the proxy. Access logs says ( I think this is the adequate line that indicates the error) :

TCP_MISS/500 0 POST http://www.abc.com:10085/cgi-bin/some.cgi - DIRECT/www.abc.com -

I have been snooping on the proxy and found that a reset is sent from the www-server and window size becomes zero.

TCP: ----- TCP Header -----
TCP:
TCP: Source port = 10085
TCP: Destination port = 62931
TCP: Sequence number = 343626418
TCP: Acknowledgement number = 0
TCP: Data offset = 20 bytes
TCP: Flags = 0x04
TCP: ..0. .... = No urgent pointer
TCP: ...0 .... = No acknowledgement
TCP: .... 0... = No push
TCP: .... .1.. = Reset
TCP: .... ..0. = No Syn
TCP: .... ...0 = No Fin
TCP: Window = 0
TCP: Checksum = 0xfa75
TCP: Urgent pointer = 0
TCP: No options
TCP:

Sequence analyse indicates that the web server is waiting from more data and when it does not receive any it issuses first two new ACKs on the latest received packet and then a RST. Our proxy responds with ACKing the last ACK, but the web server has propably decided that it is too late and sends another RST.

Looking att client-proxy communication indicates that the proxys window is decreasing from at start of transfer from 33580 to 828.

I have tested with FTP upload of larger (~ 5 Mb) file than the above (~200K) to an external FTP-server and there was no problem.

I am quite out in the dark here , but is this a possible squid misconfiguration/error or is the cause to seek elsewhere (may in OS-config) ? Or is it a client-proxy communication problem. It is also worth mentioning that file download i from web-server to client via proxy is OK.

Does anybody have hint of where to dig ?

/Anders
Received on Thu Nov 08 2001 - 06:22:23 MST