Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 588270 - F12: HTTP_EXPECTATION_FAILED after upgrading squid to v3.1.1
Summary: F12: HTTP_EXPECTATION_FAILED after upgrading squid to v3.1.1
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: squid
Version: 12
Hardware: i686
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jiri Skala
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-03 11:10 UTC by Frantisek Hanzlik
Modified: 2014-11-09 22:32 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-05-03 12:43:03 UTC
Type: ---

Attachments (Terms of Use)
screenshot of client HTTP request, as displayed in wireshark (27.46 KB, image/png)
2010-05-03 11:12 UTC, Frantisek Hanzlik 		no flags Details
Add an attachment (proposed patch, testcase, etc.)

Description Frantisek Hanzlik 2010-05-03 11:10:41 UTC 
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@kreiner.cz
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@kreiner.cz
icp_port 3130
coredump_dir /var/spool/squid


I attach screenshot of request packet info, as displayed in wireshark.
Comment 1 Frantisek Hanzlik 2010-05-03 11:12:37 UTC 
Created attachment 410942 [details]
screenshot of client HTTP request, as displayed in wireshark
Comment 2 Henrik Nordström 2010-05-03 12:43:03 UTC 
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.
Comment 3 Frantisek Hanzlik 2010-05-03 13:22:37 UTC 
Yes, I see, this in explained in RFC2616.
Many thanks for express solution!
Note You need to log in before you can comment on or make changes to this bug.