HTTP POST gibt Fehler: 417 „Expectation verlassen.“

Question

Wenn ich versuche, auf eine URL POST es in der folgenden Ausnahme ergibt:

  

Der Remote-Server hat einen Fehler zurückgegeben:   (417) Prognose fehlgeschlagen.

Hier ist ein Beispielcode:

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.

Unter Verwendung eines HttpWebRequest/HttpWebResponse Paar oder ein HttpClient keinen Unterschied machen.

Was diese Ausnahme verursacht?

Answer 1

System.Net.HttpWebRequest fügt der Kopfzeile 'HTTP-Header "Expect: 100-Continue"' auf jede Anfrage, wenn Sie es ausdrücklich fragen nicht, indem diese statische Eigenschaft auf false:

System.Net.ServicePointManager.Expect100Continue = false;

Drossel Einige Server an diesem Header und den 417 Fehler zurückschicken Sie sehen.

Geben Sie

, dass ein Schuss.

Answer 2

Eine andere Art und Weise -

Fügen Sie diese Zeilen zu Ihrer Anwendung Konfigurationsdatei Konfigurationsabschnitt:

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

Answer 3

Die gleiche Situation und Fehler können auch mit einem Standard-Assistenten generierten SOAP-Web-Service-Proxy entstehen (nicht 100%, wenn dies auch der Fall auf dem System.ServiceModel Stapel WCF ist), wenn zur Laufzeit:

• die Endbenutzer-Maschine (in den Internet-Einstellungen) konfiguriert ist, einen Proxy zu verwenden, die nicht HTTP 1.1
verstehen
• wird der Client beendet, um etwas zu senden, die ein HTTP 1.0-Proxy (allgemein einen Expect Header als Teil eines HTTP POST oder PUT Anfrage aufgrund einer Standard-Protokollkonvention des Sendens der Anforderung in zwei Teilen verstehen tut wie in den Erläuterungen hier bedeckt )

... was ein 417.

Wie in den anderen Antworten abgedeckt, wenn das spezifische Problem, das Sie in laufen ist, dass der Expect Header das Problem verursacht, dann ist das spezifische Problem aus dem indem zweiteiligen PUT / POST geroutet um einen relativ globalen Schalt werden kann Übertragung über System.Net.ServicePointManager.Expect100Continue .

Dies gilt jedoch nicht das komplette zugrunde liegende Problem beheben - der Stapel immer noch sein kann HTTP 1.1 bestimmte Dinge mit wie Keepalives usw. (. Obwohl in vielen Fällen die anderen Antworten die wichtigsten Fälle decken)

Das eigentliche Problem ist jedoch, dass der automatisch generierten Code geht davon aus, dass es OK ist, blind zu gehen mit HTTP 1.1 Einrichtungen wie jeder diese versteht. Um diese Annahme zu stoppen für ein bestimmtes Web-Service-Proxy kann man außer Kraft setzen ändert der Standard HttpWebRequest.ProtocolVersion von dem Standard von 1,1 durch eine abgeleitete Proxy-Klasse zu schaffen, die überschreibt protected override WebRequest GetWebRequest(Uri uri) wie in diesem Beitrag gezeigt: -

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

(wobei MyWS ist der Proxy die Webverweis hinzufügen Assistenten auf Sie ausgespuckt.)

---

UPDATE: Hier ist ein impl ich in der Produktion bin mit:

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 };
    }
}

Answer 4

Hat das Formular, das Sie versuchen, zwei Felder zu emulieren hat, Benutzername und Passwort?

Wenn ja, diese Zeile:

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

ist nicht korrekt.

Sie müssen zwei Zeilen wie:

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

Edit:

Okay, da dies nicht das Problem ist, ein Weg, dies zu bekämpfen ist so etwas wie Fiddler oder Wireshark zu verwenden, um zu sehen, was aus dem Browser, erfolgreich dann an den Webserver gesendet wird vergleichen, dass zu dem, was aus gesendet wird Ihre Code. Wenn Sie zu einem normalen Port 80 von .Net werden, Fiddler werden noch diesen Verkehr erfassen.

Es gibt wahrscheinlich einig anderes verstecktes Feld auf dem Formular, dass der Web-Server erwartet, dass Sie nicht senden.

Answer 5

Lösung von Proxy-Seite, traf ich auf einige Probleme bei dem SSL-Handshake-Prozess und ich musste meinen Proxy-Server zwingen, Anfragen zu senden mit HTTP / 1.0 das Problem, indem dieses Argument in der httpd.conf SetEnv force-proxy-request-1.0 1 zu lösen SetEnv proxy-nokeepalive 1 nach, dass ich die 417 Fehler wie meine Kunden Anwendung konfrontiert wurde mit HTTP / 1.1 und der Proxy wurde gezwungen, die Verwendung von HTTP / 1.0, das Problem, indem diese Parameter in der httpd.conf auf der Proxy-Seite RequestHeader unset Expect early ohne die Notwendigkeit gelöst wurde ändern, um alles in der Client-Seite, hofft, das hilft.

Answer 6

Für Powershell ist es

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

Answer 7

Wenn Sie mit „ Httpclient “, und Sie wollen nicht, globale Konfiguration verwenden, alles, was Sie zu beeinflussen programmieren Sie verwenden können:

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

ich Sie verwenden " WebClient " Ich glaube, Sie können versuchen, diesen Header zu entfernen, durch den Aufruf:

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

Answer 8

In meiner Situation, scheint dieser Fehler nur auftritt, wenn mein Client-Computer eine strenge Firewall-Richtlinie hat, die von der Kommunikation mit dem Web-Dienst meines Programm verhindert.

So einzige Lösung, die ich finden konnte, den Fehler zu fangen und informieren Benutzer über manuell die Firewall-Einstellungen zu ändern.

Answer 9

Die web.config Ansatz funktioniert für InfoPath Formular Services ruft IntApp Webservice aktiviert Regeln.

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