Hi guys, We're running Sharepoint 2007 here and I have absolutely no problems with a transparent squid proxy. I want to add in the HTTP/1.1 patch, but for now we're using stock SQUID 2.6STABLE12. This, of course, is extremely inefficient for NTLM, but works surprisingly well. I have an extremely basic configuration: http_port 80 transparent client_persistent_connections on server_persistent_connections on persistent_connection_after_error on The HTTP/1.1 patch w/ SQUID-CVS works, but breaks with persistent_connection_after_error, which is required for NTLM. It's on my plate to look at sooner or later. I don't know if you're using NTLM, but if not, you should check out the CVS version with Henrik's 1.1 patch. Scott -----Original Message----- From: Mike Withers [mailto:m.withers@xxxxxxxxxx] Sent: Wednesday, April 18, 2007 9:13 PM To: 'Caleb Anthony' Cc: squid-users@xxxxxxxxxxxxxxx Subject: RE: Squid Not Forwarding Authentication Information To SharePoint Anthony I posted in May and October 2006 on a similar problem with no success. Here is what I know so far: -----Original Message----- From: Caleb Anthony [mailto:caleb.anthony@xxxxxxxxx] Sent: Wednesday, 18 April 2007 7:49 AM To: squid-users@xxxxxxxxxxxxxxx Subject: Squid Not Forwarding Authentication Information To SharePoint Hello, I am currently testing out Squid as a reverse proxy for Microsoft SharePoint services. <comment>Share point uses front-page extensions. A similar problem as I was looking at front page to upload files to a web server.</comment> So far everything web-based is working great. Squid is passing credentials to the back end server correctly through the use of login=PASS, pages are loading correctly, etc... There is one problem however. When a user opens up a Word document, and tries to save or save as, the save/save as window hangs for about 30 - 45 seconds, and then eventually loads a much different looking window than if not going through the reverse proxy. I can post screenshots if it will help. I finally turned on a packet sniffer to watch the traffic. I saved two sessions: one using the proxy and one going direct to the server. The only difference that I see is that the proxy isn't forwarding the WWW-Authenticate header when performing the save/save as. Going direct to the SharePoint server: GET /Shared%20Documents/Forms/AllItems.aspx HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */* Accept-Language: en-us Accept-Encoding: gzip, deflate If-Modified-Since: Tue, 17 Apr 2007 20:19:37 GMT User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; IE6SP1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727) Host: xxxxxxx.xx.xx.xxx.xxx:4458 Connection: Keep-Alive Cookie: WSS_KeepSessionAuthenticated=4458; MSOWebPartPage_AnonymousAccessCookie=4458 Authorization: Negotiate xxxxx HTTP/1.1 200 OK Cache-Control: private, max-age=0 Content-Length: 56495 Content-Type: text/html; charset=utf-8 Expires: Mon, 02 Apr 2007 20:19:52 GMT Last-Modified: Tue, 17 Apr 2007 20:19:52 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET MicrosoftSharePointTeamServices: 12.0.0.4518 WWW-Authenticate: Negotiate xxxxx X-AspNet-Version: 2.0.50727 Set-Cookie: WSS_KeepSessionAuthenticated=4458; path=/ Set-Cookie: MSOWebPartPage_AnonymousAccessCookie=4458; expires=Tue, 17-Apr-2007 20:49:52 GMT; path=/ Set-Cookie: http%3A%2F%2Fxxxxxxx%2Exx%2Exx%2Exxx%2Exxx%3A4458%2FDiscovery=WorkspaceS iteN ame=xxx&WorkspaceSiteUrl=xxx&WorkspaceSiteTime=xxx; expires=Thu, 17-May-2007 20:19:52 GMT; path=/_vti_bin/Discovery.asmx Date: Tue, 17 Apr 2007 20:19:51 GMT Now through the proxy: GET /Shared%20Documents/Forms/AllItems.aspx HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */* Referer: http://xx.xxx.xx.xxx:4458/default.aspx Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; IE6SP1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727) Host: xx.xxx.xx.xxx:4458 Connection: Keep-Alive Authorization: Negotiate xxxxx Cookie: MSOWebPartPage_AnonymousAccessCookie=4458; WSS_KeepSessionAuthenticated=4458 HTTP/1.0 200 OK Date: Tue, 17 Apr 2007 20:25:15 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET MicrosoftSharePointTeamServices: 12.0.0.4518 X-AspNet-Version: 2.0.50727 Set-Cookie: WSS_KeepSessionAuthenticated=4458; path=/ Set-Cookie: MSOWebPartPage_AnonymousAccessCookie=4458; expires=Tue, 17-Apr-2007 20:55:15 GMT; path=/ Set-Cookie: http%3A%2F%2Fxx%2Exxx%2Exx%2Exxx%3A4458%2FDiscovery=WorkspaceSiteName=xx x&Wo rkspaceSiteUrl=xxx&WorkspaceSiteTime=xxx; expires=Thu, 17-May-2007 20:25:15 GMT; path=/_vti_bin/Discovery.asmx Cache-Control: private, max-age=0 Expires: Mon, 02 Apr 2007 20:25:15 GMT Last-Modified: Tue, 17 Apr 2007 20:25:15 GMT Content-Type: text/html; charset=utf-8 Content-Length: 56318 X-Cache: MISS from xx.xxx.xx.xxx X-Cache-Lookup: MISS from xx.xxx.xx.xxx:80 Via: 1.0 xx.xxx.xx.xxx:80 (squid/2.6.STABLE12) Connection: keep-alive Any suggestions would be appreciated. Thanks. <comment>The problem is at several levels. The frontpage extensions require HTTP1.1. Squid currently doesn't do this but I seem to remember a post a while ago about a patch in one of the nightly builds. The next problem is that the session setup to authorisation seems to require a series of zero content messages where the header info is part of session initiation. It also seems that (and I'm guessing here) that the frontpage extensions require the zero content body to be passed as well. I've seen somewhere info that currently the caching part of the squid code doesn't cache zero content body messages and that Adrian Chadd was looking at modifying the code to deal with this. Hope this helps. I haven't had time to dig any further.</comment>
