HTTP POST devuelve el error: 417 "Expectativa fallida".

Cuando intento PUBLICAR en una URL, aparece la siguiente excepción:

El servidor remoto devolvió un error: (417) Expectativa fallida.

Aquí hay un código de muestra:

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.

Usar un HttpWebRequest/HttpWebResponsepar o un HttpClientno hace la diferencia.

¿Qué está causando esta excepción?

System.Net.HttpWebRequest agrega el encabezado 'Encabezado HTTP "Esperar: 100-Continuar"' a cada solicitud a menos que explícitamente le pida que no establezca esta propiedad estática en falso:

System.Net.ServicePointManager.Expect100Continue = false;

Algunos servidores se ahogan con ese encabezado y devuelven el error 417 que está viendo.

Dale una oportunidad.

De otra manera -

Agregue estas líneas a la sección de configuración del archivo de configuración de su aplicación:

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

Esta misma situación y error también pueden surgir con un proxy de servicio web SOAP generado por asistente predeterminado (no 100% si este es también el caso en la System.ServiceModelpila de WCF ) cuando está en tiempo de ejecución:

• la máquina del usuario final está configurada (en la Configuración de Internet) para usar un proxy que no comprende HTTP 1.1
• el cliente termina enviando algo que un proxy HTTP 1.0 no comprende (comúnmente un Expectencabezado como parte de un HTTP POSTo PUTsolicitud debido a una convención de protocolo estándar de enviar la solicitud en dos partes como se cubre en los Comentarios aquí )

... produciendo un 417.

Como se explica en las otras respuestas, si el problema específico con el que se encuentra es que el Expectencabezado está causando el problema, entonces ese problema específico se puede enrutar haciendo una desconexión relativamente global de la transmisión PUT / POST de dos partes a través de System.Net.ServicePointManager.Expect100Continue.

Sin embargo, esto no soluciona el problema subyacente completo: la pila aún puede estar usando cosas específicas de HTTP 1.1 como KeepAlives, etc. (aunque en muchos casos las otras respuestas cubren los casos principales).

Sin embargo, el problema real es que el código autogenerado supone que está bien usar ciegamente las funciones de HTTP 1.1, ya que todos entienden esto. Para detener esta suposición para un proxy de servicio web específico, uno puede cambiar anular el valor subyacente HttpWebRequest.ProtocolVersionpredeterminado del valor predeterminado de 1.1 creando una clase de proxy derivada que se anula como se muestra en esta publicación :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;
    }
}

(¿dónde MyWSestá el proxy que el asistente para agregar referencias web le escuchó?)

ACTUALIZACIÓN: Aquí hay un impl que estoy usando en producción:

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

¿El formulario que intenta emular tiene dos campos, nombre de usuario y contraseña?

Si es así, esta línea:

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

no es correcto.

necesitarías dos líneas como:

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

Editar:

De acuerdo, ya que ese no es el problema, una forma de abordar esto es usar algo como Fiddler o Wireshark para ver lo que se envía al servidor web desde el navegador con éxito, luego compararlo con lo que se envía desde su código. Si va a un puerto 80 normal desde .Net, Fiddler aún capturará este tráfico.

Probablemente haya algún otro campo oculto en el formulario que el servidor web espera que no envíe.

Solución del lado del proxy, enfrenté algunos problemas en el proceso de protocolo de enlace SSL y tuve que forzar a mi servidor proxy a enviar solicitudes usando HTTP / 1.0 para resolver el problema configurando este argumento en httpd.conf SetEnv force-proxy-request-1.0 1 SetEnv proxy-nokeepalive 1después de eso, me enfrenté al error 417 como la aplicación de mis clientes estaba usando HTTP / 1.1 y el proxy se vio obligado a usar HTTP / 1.0, el problema se resolvió configurando este parámetro en httpd.conf en el lado del proxy RequestHeader unset Expect earlysin la necesidad de cambiar nada en el lado del cliente, espero que esto ayude .

Para Powershell es

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

Si está utilizando " HttpClient " y no desea utilizar la configuración global para afectar a todos los programas que puede utilizar:

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

Si está utilizando " WebClient ", creo que puede intentar eliminar este encabezado llamando a:

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

En mi situación, este error parece ocurrir solo si la computadora de mi cliente tiene una estricta política de firewall, lo que impide que mi programa se comunique con el servicio web.

Entonces, la única solución que pude encontrar es detectar el error e informar al usuario sobre cómo cambiar la configuración del firewall manualmente.

El enfoque web.config funciona para las llamadas de servicios de formulario de InfoPath a las reglas habilitadas del servicio web IntApp.

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