Hi, I have found some time to go further in the investigation. And here is status right now. the behavior is the some with only 1 squid ( no upstream server ), and is also the same if I use squid as a reverse proxy for the Sharepoint server. As read is some threads about this subject, depending ont the browser / OS, behaviour differes. IE in XP works perfectly, whereas FF in XP or linux asks for authentification in a loop whenever trying to upload a relatively big file to the server. Activating the debug level and trying to analyse the headers of the packets gave me quite some headache! What we can see is that the HTTP headers and techniques for POSTing files used are totally differents between browser. I would love some help on analysing these logs. Joined are 2 files : capture_IE_XP : upload of a file works capture_FF_XP : upload of a file does not I can provide access to the sharepoint server & reverse proxy if someone has time to jump in. Best regards Alex 2013/2/13 Amos Jeffries <squid3@xxxxxxxxxxxxx>: > On 13/02/2013 3:49 a.m., Alexandre Chappaz wrote: >> >> Hi, >> >> I know this is a subject that has been put on the table many times, >> but I wanted to share with you my experience with squid + sharepoint. >> >> Squid Cache: Version 3.2.7-20130211-r11781 >> >> I am having an issue with autehtication : >> when accessing the sharepoint server, I do get a login/pw popup, I can >> login and see some of the pages behind, but when doing some operation, >> even though I am supposed to be logged in, the autentcation popup >> comes back. >> Here is what I find the the access log : >> 1360679927.561 43 X.X.X.X TCP_MISS/200 652 GET >> http://saralex.hd.free.fr/_layouts/images/selbg.png - >> FIRSTUP_PARENT/192.168.100.XX image/png > > > URL #1. No authentication required. non-pinned connection used. > > >> 1360679928.543 37 X.X.X.X TCP_MISS/401 542 GET >> http://saralex.hd.free.fr/_layouts/listform.aspx? - >> PINNED/192.168.100.XX - > > > URL #2. Sent to upstream on already authenticated+PINNED connection. > Upstream server requires further authentication details. > --> authentication challenge? > > >> 1360679928.665 58 X.X.X.X TCP_MISS/401 795 GET >> http://saralex.hd.free.fr/_layouts/listform.aspx? - >> PINNED/192.168.100.XX - > > > URL #2 repeated. Sent to upstream on already authenticated+PINNED > connection. Upstream server requires further authentication details. > --> possibly authentication handshake request? > > >> 1360679928.753 229 X.X.X.X TCP_MISS/200 20625 GET >> http://saralex.hd.free.fr/_layouts/images/fgimg.png - >> FIRSTUP_PARENT/192.168.100.XX image/png > > > URL #3. No authentication required. non-pinned connection used. > > >> 1360679928.788 68 X.X.X.X TCP_MISS/302 891 GET >> http://saralex.hd.free.fr/_layouts/listform.aspx? - >> PINNED/192.168.100.XX text/html > > > URL #2 repeated. Sent to upstream on already authenticated+PINNED > connection. Upstream server redirectes the client to another URL. > --> authentication credentials accepted. > > >> 1360679928.921 45 X.X.X.X TCP_MISS/401 542 GET >> http://saralex.hd.free.fr/Lists/Tasks/NewForm.aspx? - >> PINNED/192.168.100.XX - > > > URL #4. Sent to upstream on already authenticated+PINNED connection. > Upstream server requires further authentication details. > --> authentication challenge? > > >> 1360679929.019 47 X.X.X.X TCP_MISS/401 795 GET >> http://saralex.hd.free.fr/Lists/Tasks/NewForm.aspx? - >> PINNED/192.168.100.XX - > > > URL #4 repeated. Sent to upstream on already authenticated+PINNED > connection. Upstream server requires further authentication details. > --> possibly authentication handshake request? > > >> 1360679929.656 81 X.X.X.X TCP_MISS/200 1986 GET >> http://saralex.hd.free.fr/_layouts/images/loadingcirclests16.gif - >> FIRSTUP_PARENT/192.168.100.XX image/gif > > > URL #5. no authentication required. non-pinned connection used. > > >> 1360679930.417 1322 X.X.X.X TCP_MISS/200 130496 GET >> http://saralex.hd.free.fr/Lists/Tasks/NewForm.aspx? - >> PINNED/192.168.100.XX text/html > > > URL #4 repeated. Sent to upstream on already authenticated+PINNED > connection. Upstream server provides the display response. > --> authentication credentials accepted. > > >> 1360679934.618 53 X.X.X.X TCP_MISS/401 542 GET >> http://saralex.hd.free.fr/_layouts/iframe.aspx? - >> PINNED/192.168.100.XX - >> 1360679934.729 51 X.X.X.X TCP_MISS/401 795 GET >> http://saralex.hd.free.fr/_layouts/iframe.aspx? - >> PINNED/192.168.100.XX - >> >> could this be a pinning issue? >> >> Is V2.7 STABLE managing these things in a nicer way? > > > Unknown. But I doubt it. This is Squid using a PINNED connection to relay > traffic to an upstream server. That upstream server is rejecting the clients > delivered credentials after each object. There is no sign of proxy > authentication taking place, this re-challenge business is all between > client and upstream server. > > You need to look at whether these connections are being pinned then closed, > and why that is happening. Squid-3.2 offers debug level 11,2 which will give > you a trace of the HTTP headers to see if the close is a normal operation > from either end. Or whether they are keep-alive by Squid and the upstream > server is just constantly forcing re-auth (it happens). > > Amos
Attachment:
cachelogs.tar.gz
Description: GNU Zip compressed data
