On 12/03/2015 8:59 a.m., dweimer wrote: > On 03/11/2015 1:16 am, Alex Samad wrote: >> This is mine against 2008. haven't had any issues with attachments up >> to 10M >> >> >> cache_peer 127.0.0.1 parent 443 0 proxy-only no-query no-digest >> originserver login=PASS ssl sslflags=DONT_VERIFY_PEER >> sslcert=/etc/httpd/conf.d/o.crt sslkey=/etc/httpd/conf.d/o.key >> name=webServer >> cache_peer 10.32.69.11 parent 443 0 proxy-only no-query no-digest >> originserver login=PASS front-end-https=on ssl >> sslflags=DONT_VERIFY_PEER sslcert=/etc/httpd/conf.d/o.crt >> sslkey=/etc/httpd/conf.d/o.key name=exchangeServer >> >> # List of acceptable URLs to send to the Exchange server >> acl exch_url url_regex -i <o>/exchange >> acl exch_url url_regex -i <o>/exchweb >> acl exch_url url_regex -i <o>/public >> acl exch_url url_regex -i <o>/owa >> acl exch_url url_regex -i <o>/ecp >> acl exch_url url_regex -i <o>/microsoft-server-activesync >> acl exch_url url_regex -i <o>/rpc >> acl exch_url url_regex -i <o>/rpcwithcert >> acl exch_url url_regex -i <o>/exadmin >> acl exch_url url_regex -i <o>/oab >> >> # Send the Exchange URLs to the Exchange server >> cache_peer_access exchangeServer allow exch_url >> >> # Send everything else to the Apache >> cache_peer_access webServer deny exch_url >> >> # This is to protect Squid >> never_direct allow exch_url >> >> # Logging Configuration >> redirect_rewrites_host_header off >> cache_mem 32 MB >> maximum_object_size_in_memory 128 KB >> cache_log none >> cache_store_log none >> >> access_log /var/log/squid/office-access.log squid >> #access_log none >> cache_log /var/log/squid/office-cache.log >> #cache_log none >> pid_filename /var/run/squid-office.pid >> >> >> # Set the hostname so that we can see Squid in the path (Optional) >> visible_hostname <o> >> deny_info TCP_RESET all >> >> # ACL - required to allow >> #acl all src ALL >> >> # Allow everyone through, internal and external connections >> http_access allow all >> miss_access allow all >> >> icp_port 0 >> snmp_port 0 >> >> via off >> >> On 11 March 2015 at 15:42, dweimer <dweimer@xxxxxxxxxxx> wrote: >>> We have setup Squid as a reverse proxy to Exchange 2010 OWA server we >>> thought everything was working OK, but found out that any file >>> attachments >>> over 2MB cause a timeout after 5 minutes. I remembered having this >>> issue a >>> while back with HTTPS, and it just went away after some updates. Some >>> searching found other users posting messages to the Squid mailing >>> list that >>> had this issue in particular with OWA. However I never found a fix on >>> any of >>> the threads. >>> >>> Squid is currently running 3.4.11, on FreeBSD 10.1-RELEASE-p5, This >>> occurs >>> even when sending the file through the local network passing through the >>> reverse proxy. With the slowest link being a 1G. >>> >>> Below is the relevant parts of the configuration, with some information >>> excluded for security >>> https_port 10.50.20.12:443 accel defaultsite=... \ >>> cert=... \ >>> key=... \ >>> options=NO_SSLv2:NO_TLSv1:CIPHER_SERVER_PREFERENCE \ >>> cipher=RC4:!MD5:!aNULL:!EDH >>> >>> cache_peer ... parent 443 0 ssl no-query no-digest no-netdb-exchange >>> originserver name=owa2010_parent sslcapath=/usr/local/share/certs >>> sslflags=DONT_VERIFY_PEER login=PASSTHRU front-end-https=on >>> >>> We also host sharepoint (certificate is a wildcard certificate) this >>> way as >>> well, and I have just verified that it has the same problem. It is >>> served by >>> the same https_port line, and a different cache_peer the only >>> difference is >>> the IP and it doesn't have the front-end-https option set. >>> >>> Does anyone have any ideas to check? >>> >>> is this possibly a cause >>> <http://www.squid-cache.org/Doc/config/broken_posts/>? >>> > > I don't believe OWA has anything to do with my problem, it appears to be > related entirely to posting with HTTPS using the reverse proxy. I ran > into this after the upgrade from squid 3.1 to 3.2 back on FreeBSD > version 9.0 & 9.1. I never did find the answer to the issue then, it > finally just went away after the upgrade to squid 3.3. At the time the > application I was using was using that was affected was running on > Apache and PHP, that application is still run from this reverse proxy > server as well but apparently unaffected by the problem now. It's > current version uses an uploader process that uses java to chunk the > files into smaller pieces during upload. > > What appears to happen is that the client sends the entire file to the > Squid Reverse Proxy server, but somehow at the end of the file Squid > never receives an expected end of file from the client. The client > believes that everything is sent and sits waiting until it times out. > > Oddly enough when I put fiddler on my laptop to capture the HTTPS > traffic in a decrypted method so that I could see more information into > what was happening. It succeeds if the browser is talking to fiddler, > which is talking to the reverse proxy which is talking to the end > server. Why adding fiddler to this chain of options fixes it is well > beyond my understanding. > > I am working on setting up a more simplified VM with mimimal settings in > that I can run debugging in to get a better logs to help with the issue > the current system has to much traffic on it. Does anyone have any > suggestions for which debugging level I should use for squid in order to > attempt to get useful logs to troubleshoot this? > debug_options ALL,9 if you are using a lab setup like that with easily repeatable test. It could be related to the issue for which broken_posts exists, but that directive will probably only help if Squid is aware that it has the entire request payload. Or it could be Squid is stuck with only 1-2 bytes of buffer space available and waiting for the server to drain it. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
