When I try to POST to a URL it results in the following exception:
The remote server returned an error: (417) Expectation Failed.
Here's a sample code:
var client = new WebClient();
var postData = new NameValueCollection();
postData.Add("postParamName", "postParamValue");
byte[] responseBytes = client.UploadValues("http://...", postData);
string response = Encoding.UTF8.GetString(responseBytes); // (417) Expectation Failed.
Using an HttpWebRequest/HttpWebResponse
pair or an HttpClient
doesn't make a difference.
What's causing this exception?
The web.config approach works for InfoPath form services calls to IntApp web service enabled rules.
Solution from proxy side, I faced some problems in the SSL handshake process and I had to force my proxy server to send requests using HTTP/1.0 to solve the problem by setting this argument in the httpd.conf
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
after that I faced the 417 error as my clients application was using HTTP/1.1 and the proxy was forced to use HTTP/1.0, the problem was solved by setting this parameter in the httpd.conf on the proxy sideRequestHeader unset Expect early
without the need to change anything in the client side, hope this helps.For Powershell it is
This same situation and error can also arise with a default wizard generated SOAP Web Service proxy (not 100% if this is also the case on the WCF
System.ServiceModel
stack) when at runtime:Expect
header as part of a HTTPPOST
orPUT
request due to a standard protocol convention of sending the request in two parts as covered in the Remarks here)... yielding a 417.
As covered in the other answers, if the specific issue you run into is that the
Expect
header is causing the problem, then that specific problem can be routed around by doing a relatively global switching off of the two-part PUT/POST transmission viaSystem.Net.ServicePointManager.Expect100Continue
.However this does not fix the complete underlying problem - the stack may still be using HTTP 1.1 specific things such as KeepAlives etc. (though in many cases the other answers do cover the main cases.)
The actual problem is however that the autogenerated code assumes that it's OK to go blindly using HTTP 1.1 facilities as everyone understands this. To stop this assumption for a specific Web Service proxy, one can change override the default underlying
HttpWebRequest.ProtocolVersion
from the default of 1.1 by creating a derived Proxy class which overridesprotected override WebRequest GetWebRequest(Uri uri)
as shown in this post:-(where
MyWS
is the proxy the Add Web Reference wizard spat out at you.)UPDATE: Here's an impl I'm using in production:
If you are using "HttpClient", and you don't want to use global configuration to affect all you program you can use:
I you are using "WebClient" I think you can try to remove this header by calling:
Another way -
Add these lines to your application config file configuration section: