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

Can you please try a Squid-2.5 development snapshot. The way POST/PUT is
dealt with has been completely rewritten since Squid-2.4.

Regards
Henrik Nordström
MARA Systems AB, Sweden

On Thursday 08 November 2001 14.22, Anders Strandberg (EPL) wrote:
> 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 - 08:34:27 MST