Description of problem: After upgrading squid (perhaps v3.1.0.17) to squid-3.1.1-1.fc12.i386, build date 30-Mar-2010, some our application which sent data over HTTP stop working, as SQUID at its POST request return error 417 (HTTP_EXPECTATION_FAILED). Relevant line in access.log is: 1272874075.717 0 192.168.1.47 NONE/417 4256 POST http://app1.geis.cz/Invio/WebServices/Auth.asmx - NONE/- text/html After inspecting squid incoming and outcoming trafic in this case, it seems as this error is generated directly by squid, without intervening destination webserver. SQUID is configured as standalone cache, without transparent access. It's config: acl manager proto cache_object acl localhost src 127.0.0.1/32 acl to_localhost dst 127.0.0.0/8 acl localnet src 192.168.0.0/19 # RFC1918 possible internal network acl badlocalnet src 192.168.1.64/26 # hrisnici na pevnych IP 192.168.1.64 - .127 acl SSL_ports port 443 acl SSL_ports port 4433 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 4433 # https-dspam acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT http_access allow manager localhost http_access deny manager http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access deny badlocalnet http_access allow localnet http_access allow localhost http_access deny all icp_access allow localnet icp_access deny all htcp_access allow localnet htcp_access deny all http_port 3128 hierarchy_stoplist cgi-bin ? access_log /var/log/squid/access.log squid ftp_user Squid refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern (cgi-bin|\?) 0 0% 0 refresh_pattern . 0 20% 4320 cache_mgr support icp_port 3130 coredump_dir /var/spool/squid I attach screenshot of request packet info, as displayed in wireshark.
Created attachment 410942 [details] screenshot of client HTTP request, as displayed in wireshark
THis is a bug in the requesting client application. Clients sending "Expect: 100-continue" SHOULD be perparared for that expectation to fail with an 417 Expectation failed and then retry without the expecation. The reason why you are now seeing these with Squid is because more and more of the HTTP/1.1 standard is being implemented. There is a simple workaround if fixing the client application is not an option and it's to instruct Squid to silently ignore the 100-continue expecation sent by the client. This is done by setting "ignore_expect_100 on" in squid.conf.
Yes, I see, this in explained in RFC2616. Many thanks for express solution!