HTTP POST gibt Fehler zurück: 417 "Erwartung fehlgeschlagen."

Wenn ich versuche, auf eine URL zu posten, führt dies zu der folgenden Ausnahme:

Der Remote-Server hat einen Fehler zurückgegeben: (417) Erwartung 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.

Die Verwendung eines HttpWebRequest/HttpWebResponsePaares oder eines HttpClientmacht keinen Unterschied.

Was verursacht diese Ausnahme?

System.Net.HttpWebRequest fügt jeder Anforderung den Header 'HTTP-Header "Expect: 100-Continue"' hinzu, es sei denn, Sie fordern dies ausdrücklich nicht an, indem Sie diese statische Eigenschaft auf false setzen:

System.Net.ServicePointManager.Expect100Continue = false;

Einige Server ersticken an diesem Header und senden den angezeigten 417-Fehler zurück.

Probieren Sie es aus.

Ein anderer Weg -

Fügen Sie diese Zeilen zum Konfigurationsabschnitt Ihrer Anwendungskonfigurationsdatei hinzu:

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

Dieselbe Situation und dieser Fehler können auch bei einem vom Standardassistenten generierten SOAP-Webdienst-Proxy (nicht 100%, wenn dies auch auf dem WCF- System.ServiceModelStapel der Fall ist ) zur Laufzeit auftreten:

• Der Endbenutzercomputer ist (in den Interneteinstellungen) so konfiguriert, dass er einen Proxy verwendet, der HTTP 1.1 nicht versteht
• Der Client sendet am Ende etwas, das ein HTTP 1.0-Proxy nicht versteht (normalerweise ein ExpectHeader als Teil eines HTTP POSToder einer PUTAnforderung aufgrund einer Standardprotokollkonvention zum Senden der Anforderung in zwei Teilen, wie in den Anmerkungen hier beschrieben ).

... ergibt eine 417.

Wie in den anderen Antworten beschrieben, kann das spezifische Problem, wenn Sie darauf stoßen, dass der ExpectHeader das Problem verursacht, durch ein relativ globales Abschalten der zweiteiligen PUT / POST-Übertragung über umgeleitet werden System.Net.ServicePointManager.Expect100Continue.

Dies behebt jedoch nicht das vollständige zugrunde liegende Problem - der Stack verwendet möglicherweise immer noch HTTP 1.1-spezifische Dinge wie KeepAlives usw. (obwohl in vielen Fällen die anderen Antworten die Hauptfälle abdecken.)

Das eigentliche Problem ist jedoch, dass der automatisch generierte Code davon ausgeht, dass es in Ordnung ist, HTTP 1.1-Funktionen blind zu verwenden, da dies jeder versteht. Um diese Annahme für einen bestimmten Webdienst-Proxy zu beenden, können Sie die Überschreibung der zugrunde liegenden Standardeinstellung HttpWebRequest.ProtocolVersionvon der Standardeinstellung 1.1 ändern, indem Sie eine abgeleitete Proxy-Klasse erstellen, die wie in diesem Beitrag gezeigt überschreibt : -protected override WebRequest GetWebRequest(Uri uri)

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

(Wo MyWSist der Proxy, den der Assistent zum Hinzufügen von Webreferenzen auf Sie ausgespuckt hat?)

UPDATE: Hier ist ein Gerät, das ich in der Produktion verwende:

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

Hat das Formular, das Sie emulieren möchten, zwei Felder, Benutzername und Passwort?

Wenn ja, diese Zeile:

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

das ist nicht richtig.

Sie würden zwei Zeilen benötigen wie:

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

Bearbeiten:

Okay, da dies nicht das Problem ist, besteht eine Möglichkeit, dies zu beheben, darin, mithilfe von Fiddler oder Wireshark zu beobachten, was vom Browser erfolgreich an den Webserver gesendet wird, und dies dann mit dem zu vergleichen, was von Ihrem Code gesendet wird. Wenn Sie von .Net zu einem normalen Port 80 wechseln, erfasst Fiddler diesen Datenverkehr weiterhin.

Es gibt wahrscheinlich ein anderes verstecktes Feld im Formular, das der Webserver erwartet, dass Sie nicht senden.

Lösung von der Proxyseite, ich hatte einige Probleme beim SSL-Handshake-Prozess und musste meinen Proxyserver zwingen, Anforderungen über HTTP / 1.0 zu senden, um das Problem zu lösen, indem SetEnv force-proxy-request-1.0 1 SetEnv proxy-nokeepalive 1ich dieses Argument in der httpd.conf festlegte. Danach trat der Fehler 417 als auf Meine Client-Anwendung verwendete HTTP / 1.1 und der Proxy musste HTTP / 1.0 verwenden. Das Problem wurde behoben, indem dieser Parameter in der httpd.conf auf der Proxy-Seite festgelegt wurde, RequestHeader unset Expect earlyohne dass auf der Client-Seite Änderungen vorgenommen werden mussten. Ich hoffe, dies hilft .

Für Powershell ist es das

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

Wenn Sie " HttpClient " verwenden und keine globale Konfiguration verwenden möchten, um alles zu beeinflussen, was Sie programmieren können:

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

Wenn Sie " WebClient " verwenden, können Sie versuchen, diesen Header zu entfernen, indem Sie Folgendes aufrufen:

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

In meiner Situation scheint dieser Fehler nur aufzutreten, wenn der Computer meines Clients über eine strenge Firewall-Richtlinie verfügt, die verhindert, dass mein Programm mit dem Webdienst kommuniziert.

Die einzige Lösung, die ich finden konnte, besteht darin, den Fehler abzufangen und den Benutzer über das manuelle Ändern der Firewall-Einstellungen zu informieren.

Der web.config-Ansatz funktioniert für InfoPath-Formulardienstaufrufe an Regeln, die für IntApp-Webdienste aktiviert sind.

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