HTTP POST retorna erro: 417 "Expectation Failed".

Quando tento postar em um URL, resulta na seguinte exceção:

O servidor remoto retornou um erro: (417) Expectation Failed.

Aqui está um código de exemplo:

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 um HttpWebRequest/HttpWebResponsepar ou um HttpClientnão faz diferença.

O que está causando essa exceção?

System.Net.HttpWebRequest adiciona o cabeçalho 'HTTP header "Expect: 100-Continue"' a cada solicitação, a menos que você solicite explicitamente que não, definindo esta propriedade estática como false:

System.Net.ServicePointManager.Expect100Continue = false;

Alguns servidores engasgam com esse cabeçalho e devolvem o erro 417 que você está vendo.

Dê uma chance a isso.

Outra maneira -

Adicione estas linhas à seção de configuração do arquivo de configuração do aplicativo:

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

A mesma situação e erro também podem surgir com um proxy de serviço da Web SOAP gerado por um assistente padrão (não 100% se esse também for o caso na System.ServiceModelpilha do WCF ) quando em tempo de execução:

• a máquina do usuário final está configurada (nas Configurações da Internet) para usar um proxy que não entende o HTTP 1.1
• o cliente acaba enviando algo que um proxy HTTP 1.0 não entende (geralmente um Expectcabeçalho como parte de um HTTP POSTou PUTsolicitação devido a uma convenção de protocolo padrão de enviar a solicitação em duas partes, conforme coberto nas observações aqui )

... produzindo um 417.

Conforme abordado nas outras respostas, se o problema específico em que você se deparar for o fato de o Expectcabeçalho estar causando o problema, esse problema específico poderá ser roteado ao se fazer uma desativação relativamente global da transmissão PUT / POST em duas partes System.Net.ServicePointManager.Expect100Continue.

No entanto, isso não resolve o problema subjacente completo - a pilha ainda pode estar usando coisas específicas do HTTP 1.1, como KeepAlives etc. (embora em muitos casos as outras respostas abranjam os casos principais).

O problema real é, no entanto, que o código gerado automaticamente assume que não há problema em usar cegamente os recursos do HTTP 1.1, pois todos entendem isso. Para interromper essa suposição para um proxy de serviço da Web específico, é possível alterar a substituição do padrão subjacente HttpWebRequest.ProtocolVersiondo padrão de 1.1 , criando uma classe de proxy derivada que substitui como mostrado nesta postagem : -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;
    }
}

(onde MyWSestá o proxy que o assistente Adicionar Referência da Web cuspiu em você.)

UPDATE: Aqui está um impl estou usando na produção:

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

O formulário que você está tentando emular possui dois campos, nome de usuário e senha?

Se sim, esta linha:

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

não está correto.

você precisaria de duas linhas como:

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

Editar:

Ok, como esse não é o problema, uma maneira de resolver isso é usar algo como o Fiddler ou o Wireshark para observar o que está sendo enviado para o servidor da Web a partir do navegador com êxito e comparar com o que está sendo enviado pelo seu código. Se você estiver indo para uma porta 80 normal do .Net, o Fiddler ainda capturará esse tráfego.

Provavelmente, existe algum outro campo oculto no formulário que o servidor da Web espera que você não esteja enviando.

Solução do lado do proxy, enfrentei alguns problemas no processo de handshake SSL e tive que forçar meu servidor proxy a enviar solicitações usando HTTP / 1.0 para resolver o problema, definindo esse argumento no httpd.conf SetEnv force-proxy-request-1.0 1 SetEnv proxy-nokeepalive 1depois que enfrentei o erro 417 como meu aplicativo clientes estava usando HTTP / 1.1 e o proxy foi forçado a usar HTTP / 1.0, o problema foi resolvido definindo esse parâmetro no httpd.conf no lado proxy RequestHeader unset Expect earlysem a necessidade de alterar nada no lado cliente, espero que isso ajude .

Para o PowerShell, é

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

Se você estiver usando " HttpClient " e não quiser usar a configuração global para afetar todos os programas que você pode usar:

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

Se você estiver usando o " WebClient ", acho que você pode tentar remover esse cabeçalho chamando:

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

Na minha situação, esse erro parece ocorrer apenas se o computador do meu cliente tiver uma política rígida de firewall, o que impede que meu programa se comunique com o serviço da web.

Portanto, a única solução que pude encontrar é detectar o erro e informar o usuário sobre a alteração manual das configurações do firewall.

A abordagem web.config funciona para chamadas de serviços de formulário do InfoPath para regras habilitadas para serviços da web do IntApp.

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