HTTP POST Returns Error: 417 "Expectation Failed."

Question

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 issue seems to happen when your application communicates through a proxy server. A .NET application I wrote worked when it was directly connected to internet but not when it was behind a proxy server. — Salman A, May 24 '12 at 12:01
Observed this condition when a client is running through a HTTP 1.0 (only) proxy server. The client (asmx proxy without any configuration) is sending a HTTP 1.1 request and the proxy (before any server could ever get involved) then rejects what the proxy sends on. Should an end-user have this issue, using the [config solution below](http://stackoverflow.com/a/7358457/11635) is an appropriate workaround as it would cause requests to be generated without a reliance on the proxy understanding the `Expect` header which by default gets added as `Expect100Continue` is `true` by default. — Ruben Bartelink, Jun 06 '12 at 13:18

score 484 · Accepted Answer · answered Feb 19 '09 at 19:45

484

System.Net.HttpWebRequest adds the header 'HTTP header "Expect: 100-Continue"' to every request unless you explicitly ask it not to by setting this static property to false:

System.Net.ServicePointManager.Expect100Continue = false;

Some servers choke on that header and send back the 417 error you're seeing.

Give that a shot.

answered Feb 19 '09 at 19:45

xcud

14,422
3
33
29

5

I had some code that talked to Twitter that suddenly stopped working the day after Christmas. They'd done an upgrade or config change that caused their servers to start choking on that header. It was a pain to find the fix. – xcud Feb 19 '09 at 20:00
8

I think I picked up an extra 10 points for getting an answer accepted in a thread that Jon Skeet posted a solution into. – xcud Feb 20 '09 at 05:39
Thanks - saved me stacks of time - worked 100%. My solution used to work without this and then stopped working until I added it in... I guess they changed the config on their server..? – Madeleine Sep 21 '10 at 14:16
1

Thanks! This should be noted somewhere in msdn examples such as http://msdn.microsoft.com/en-us/library/debx8sh9.aspx – Eugene Jan 07 '11 at 21:47
Hm, didn't work for me, now I'm getting **The server committed a protocol violation. Section=ResponseStatusLine** – Nyerguds Apr 14 '11 at 17:06
well, oddly enough, after some googling I fixed the protocol violation thing simply by setting my HttpWebRequest's "KeepAlive" property to False. Weird stuff. – Nyerguds Apr 14 '11 at 17:45
25

You can also specify that property in your app.config: . http://nahidulkibria.blogspot.com/2009/06/how-to-fix-wcf-error-remote-server.html – Andre Luus Apr 29 '11 at 11:10
2

Note: this setting also applies to ServiceReferences and I assume WebReferences. – Myster Jul 28 '11 at 05:36
@Apoorva When using `HttpWebRequest` it must come before `Write`-ing to the request stream. For WebClient, probably before `UploadValues`. – Chris Nov 06 '14 at 17:10
This also made it work through Southwest's in-flight WiFi (they're using a proxy service for HTTP) – Haukman Nov 23 '14 at 03:20
Any of the solution , config file setting and System.Net.ServicePointManager.Expect100Continue = false; doesn't worked for me, I am using webclient object and PutAsJsonAsync(HttpClient, Uri, T) method to get the response from webApi but in response I am getting status 417 expectation failed . Anybody has any idea on thi problem... – Rohit Vyas Nov 19 '16 at 00:18
any idea how to do this is in java – Kiran Kumar Mar 29 '19 at 15:11
Perfect - Thank you. A very small notice. This may take into effect after several seconds/minutes you call the method. I don't know why and weird, but this has not worked out, than it worked after a few minutes. – HGMamaci Nov 14 '20 at 19:14

score 116 · Answer 2 · edited Aug 06 '16 at 12:10

116

Another way -

Add these lines to your application config file configuration section:

<system.net>
    <settings>
        <servicePointManager expect100Continue="false" />
    </settings>
</system.net>

edited Aug 06 '16 at 12:10

cst1992

3,823
1
29
40

answered Sep 09 '11 at 07:34

Engin Ardıç

2,459
1
21
19

6

Works very well when you have to make an operational change and are not ready for a code change. – dawebber Dec 07 '13 at 18:43
2

What does that line of config do? – J86 Jun 23 '16 at 08:36

Ruben Bartelink · Answer 3 · 2013-05-03T09:37:28.723

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:

the end user machine is configured (in the Internet Settings) to use a proxy that does not understand HTTP 1.1
the client ends up sending something that a HTTP 1.0 proxy doesnt understand (commonly an Expect header as part of a HTTP POST or PUT 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 via System.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 overrides protected override WebRequest GetWebRequest(Uri uri) as shown in this post:-

public class MyNotAssumingHttp11ProxiesAndServersProxy : MyWS
{
    protected override WebRequest GetWebRequest(Uri uri)
    {
      HttpWebRequest request = (HttpWebRequest)base.GetWebRequest(uri);
      request.ProtocolVersion = HttpVersion.Version10;
      return request;
    }
}

(where MyWS is the proxy the Add Web Reference wizard spat out at you.)

UPDATE: Here's an impl I'm using in production:

class ProxyFriendlyXXXWs : BasicHttpBinding_IXXX
{
    public ProxyFriendlyXXXWs( Uri destination )
    {
        Url = destination.ToString();
        this.IfProxiedUrlAddProxyOverriddenWithDefaultCredentials();
    }

    // Make it squirm through proxies that don't understand (or are misconfigured) to only understand HTTP 1.0 without yielding HTTP 417s
    protected override WebRequest GetWebRequest( Uri uri )
    {
        var request = (HttpWebRequest)base.GetWebRequest( uri );
        request.ProtocolVersion = HttpVersion.Version10;
        return request;
    }
}

static class SoapHttpClientProtocolRealWorldProxyTraversalExtensions
{
    // OOTB, .NET 1-4 do not submit credentials to proxies.
    // This avoids having to document how to 'just override a setting on your default proxy in your app.config' (or machine.config!)
    public static void IfProxiedUrlAddProxyOverriddenWithDefaultCredentials( this SoapHttpClientProtocol that )
    {
        Uri destination = new Uri( that.Url );
        Uri proxiedAddress = WebRequest.DefaultWebProxy.GetProxy( destination );
        if ( !destination.Equals( proxiedAddress ) )
            that.Proxy = new WebProxy( proxiedAddress ) { UseDefaultCredentials = true };
    }
}

I know you posted this quite a while ago, but Ruben, you are a life saver. This issue has been driving me crazy until I came across your solution and it works perfectly. Cheers! — Chris McAtackney, Dec 12 '12 at 19:54
@ChrisMcAtackney You're welcome. It definitely seemed worth the effort of documenting it at them time... the general issue set around the fringes of becoming a top-priority issue and just bothered me until I investigated it properly -- yet there didnt seem to be any google juice for that side of the issue. and it was one of that Attwood chap's posts from way back that pushed me to do it. (An upvote with a comment like this is fantastic BTW) — Ruben Bartelink, Dec 12 '12 at 21:24

Moose · Answer 4 · 2009-02-19T19:39:01.373

Does the form you are trying to emulate have two fields, username and password?

If so, this line:

 postData.Add("username", "password");

is not correct.

you would need two lines like:

 postData.Add("username", "Moose");
postData.Add("password", "NotMoosespasswordreally");

Edit:

Okay, since that is not the problem, one way to tackle this is to use something like Fiddler or Wireshark to watch what is being sent to the web server from the browser successfully, then compare that to what is being sent from your code. If you are going to a normal port 80 from .Net, Fiddler will still capture this traffic.

There is probably some other hidden field on the form that the web server is expecting that you are not sending.

score 4 · Answer 5 · answered May 28 '13 at 06:19

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 side RequestHeader unset Expect early without the need to change anything in the client side, hope this helps.

score 3 · Answer 6 · answered Mar 01 '18 at 18:03

3

For Powershell it is

[System.Net.ServicePointManager]::Expect100Continue = $false

answered Mar 01 '18 at 18:03

TNT

3,392
1
24
27

score 2 · Answer 7 · answered Jul 11 '17 at 12:45

If you are using "HttpClient", and you don't want to use global configuration to affect all you program you can use:

 HttpClientHandler httpClientHandler = new HttpClientHandler();
 httpClient.DefaultRequestHeaders.ExpectContinue = false;

I you are using "WebClient" I think you can try to remove this header by calling:

 var client = new WebClient();
 client.Headers.Remove(HttpRequestHeader.Expect);

score 0 · Answer 8 · answered Jul 21 '15 at 07:51

In my situation, this error seems to occur only if my client's computer has a strict firewall policy, which prevents my program from communicating with the web service.

So only solution I could find is to catch the error and inform user about changing the firewall settings manually.

score 0 · Answer 9 · answered Nov 06 '20 at 01:04

0

Check that your network connection isn't redirecting.

I had this issue when on the wrong wifi and any web request was redirecting to a corporate login page.

answered Nov 06 '20 at 01:04

justjoshin

114
6

score 0 · Answer 10 · answered Jul 18 '23 at 15:23

0

This can be caused by not having the correct authorization when hitting the endpoint/controller. If your controller is decorated with the AuthorizeAttribute and your request doesnt conform to that authorization, you will get a

answered Jul 18 '23 at 15:23

Dean P

1,841
23
23

score -1 · Answer 11 · answered Mar 24 '13 at 22:58

-1

The web.config approach works for InfoPath form services calls to IntApp web service enabled rules.

  <system.net>
    <defaultProxy />
    <settings> <!-- 20130323 bchauvin -->
        <servicePointManager expect100Continue="false" />
    </settings>
  </system.net>

answered Mar 24 '13 at 22:58

BobC

100
1
3

2

dup of http://stackoverflow.com/a/7358457/11635 Please comment there if you want to add a point – Ruben Bartelink Mar 09 '15 at 22:24

HTTP POST Returns Error: 417 "Expectation Failed."

11 Answers11

Linked