O servidor cometeu uma violação de protocolo. Section = ResponseStatusLine ERROR

115

Eu criei um programa, tentei postar uma string em um site e recebo este erro:

"O servidor cometeu uma violação de protocolo. Seção = ResponseStatusLine"

após esta linha de código:

gResponse = (HttpWebResponse)gRequest.GetResponse();

Como posso corrigir essa exceção?

c# httpwebrequest

— Manish Patel
fonte

71

Tente colocar isso em seu app / web.config:

<system.net>
    <settings>
        <httpWebRequest useUnsafeHeaderParsing="true" />
    </settings>
</system.net>

Se isso não funcionar, você também pode tentar definir a KeepAlivepropriedade como false.

— Darin Dimitrov
fonte

3

Eu tive 6 urls gerando este erro. Definir useUnsafeHeaderParsing corrigiu para um link, mas definir KeepAlive = false corrigiu para todos os 6.

— David Hammond

3

O mesmo pode ser colocado dentro da tag raiz <configuration> no App.copnfig para aplicativos não-web (por exemplo, eu consertei o aplicativo WPF dessa forma - obrigado!).

— Yury Schkatula de

alguém sabe por que essa medida de segurança é imposta pelo IIS? Funcionou, mas não entendo o motivo da restrição dos valores do cabeçalho (configurá-los manualmente no meu caso).

— emran

26

Isso é apenas evitar o problema, em vez de realmente corrigi-lo. Acho que essa não deve ser a solução padrão.

— Tobias

4

Concorde com Tobias - você está evitando o problema. Agora pode ser que o problema esteja em um servidor que você não pode consertar e, portanto, evitar pode ser sua única opção ... mas, ainda assim, sejamos claros sobre a diferença entre evitar um erro de protocolo e realmente corrigi-lo.

— metaforge

58

Às vezes, esse erro ocorre quando o UserAgentparâmetro de solicitação está vazio (na API github.com, no meu caso).

Definir esse parâmetro como string personalizada não vazia resolveu meu problema.

— Ivan Kochurkin
fonte

5

Ah, isso é o que eu precisava. Obrigado. Aqui está um exemplo de agente de usuário: stackoverflow.com/a/15144495/891976

— David Ruhmann

Uma linha rápida para usar WebClientaqui stackoverflow.com/a/11841680/4795214

5

Obrigado. Se você deseja consultar o GitHub via HttpClient add: client.DefaultRequestHeaders.Add("User-Agent", "Anything"); line para corrigir.

— Cihan Yakar

32

O culpado no meu caso foi retornar uma No Contentresposta, mas definir um corpo de resposta ao mesmo tempo. Que esta resposta me lembre e talvez a outros de não retornar uma NoContentresposta com um corpo nunca mais.

Este comportamento é consistente com 10.2.5 204 Nenhum conteúdo da especificação HTTP que diz:

A resposta 204 NÃO DEVE incluir um corpo de mensagem e, portanto, é sempre encerrada pela primeira linha vazia após os campos de cabeçalho.

— Tobias
fonte

Acabei de ler isso depois que recebi o The server committed a protocol violation. Section=ResponseStatusLine erro ao usar o WebApi para retornar uma NoContent()resposta personalizada que estava sendo enviada No Contentpor algum motivo bizarro! Assim que tirei isso, o problema foi embora :)

— Intrepid

2

Esse também era o meu problema, embora fosse complicado porque era a chamada DEPOIS da resposta Sem conteúdo que estava falhando.

— mdickin

Corrigido removendo someContentdo return Request.CreateResponse(HttpStatusCode.NoContent, someContent); +1

— snippetkid

12

Outra possibilidade: ao fazer um POST, o servidor responde com 100 continue de forma incorreta.

Isso resolveu o problema para mim:

request.ServicePoint.Expect100Continue = false;

— marq
fonte

Isso funcionou para mim ao acessar a API MediaFire.

— AlexPi

3

Eu sei que estou chegando tarde, mas o que você quer dizer com "de forma incorreta"?

— kuskmen

1

Para qualquer pessoa que use HttpClient , o seguinte funcionou para mim:var http = new HttpClient(); http.DefaultRequestHeaders.ExpectContinue = false;

— user2444499

9

Isso estava acontecendo comigo quando eu tinha o Skype em execução na minha máquina local. Assim que fechei, a exceção foi embora.

Ideia cortesia desta página

— Lucas
fonte

Teve o mesmo problema. Acabou por ser o Skype. É tão lamentável que mensagens adequadas não possam ser fornecidas.

— jordan koskei

você não precisa realmente fechar o Skype, acrescentei uma resposta abaixo para mostrar como lidar com isso sem fechar o Skype.

— AltF4_

8

Uma maneira de depurar isso (e ter certeza de que é a violação de protocolo que está causando o problema) é usar o Fiddler (Http Web Proxy) e ver se o mesmo erro ocorre. Se isso não acontecer (ou seja, o Fiddler tratou do problema para você), você poderá corrigi-lo usando o sinalizador UseUnsafeHeaderParsing.

Se você estiver procurando uma maneira de definir esse valor programaticamente, consulte os exemplos aqui: http://o2platform.wordpress.com/2010/10/20/dealing-with-the-server-committed-a-protocol-violation-sectionresponsestatusline /

— Dinis cruz
fonte

O Fiddler está de fato corrigindo o problema que tenho com uma solicitação GET HTTP. Podemos ver o que é feito pelo violinista?

— Olivier MATROT

8

Muitas soluções falam sobre uma solução alternativa, mas não sobre a causa real do erro.

Uma possível causa desse erro é se o servidor da web usa uma codificação diferente de ASCIIou ISO-8859-1para gerar a seção de resposta do cabeçalho. A razão de usar ISO-8859-1seria se oResponse-Phrase contiver caracteres latinos estendidos.

Outra possível causa desse erro é se um servidor da web usa o UTF-8que gera o marcador de ordem de byte (BOM). Por exemplo, a constante padrão Encoding.UTF8gera a BOM e é fácil esquecer isso. As páginas da web funcionarão corretamente no Firefox e no Chrome, mas HttpWebRequestirão bombar :). Uma solução rápida é mudar o servidor da web para usar a codificação UTF-8 que não produz o BOM, por exemplo new UTF8Encoding(false)(o que está OK, desde que Response-Phrasecontenha apenas caracteres ASCII, mas realmente deve usar ASCIIou ISO-8859-1para os cabeçalhos, e então UTF-8ou alguma outra codificação para a resposta).

— Repugnância
fonte

Esta é a melhor resposta. Isso explica por que o servidor da web está se comportando mal. Obrigado! (Tenho que emular um servidor web com soquetes devido a problemas de implantação com HttpListener.)

— Andrew Rondeau

6

Definir espera 100 continua a falso e reduzir o tempo ocioso do soquete para dois segundos resolveu o problema para mim

ServicePointManager.Expect100Continue = false; 
ServicePointManager. MaxServicePointIdleTime = 2000;

— Prashan Pratap
fonte

6

O Skype foi a principal causa do meu problema:

Este erro geralmente ocorre quando você configura o Visual Studio para depurar um aplicativo da Web existente em execução no IIS em vez do servidor Web de depuração ASP.NET integrado . O IIS escuta por padrão as solicitações da web na porta 80. Nesse caso, outro aplicativo já está escutando as solicitações na porta 80. Normalmente, o aplicativo ofensivo é o Skype, que por padrão assume a escuta nas portas 80 e 443 quando instalado. O Skype já está ocupando a porta 80. Portanto, o IIS não consegue iniciar.

Para resolver o problema, siga as etapas:

Skype -> Ferramentas -> Opções -> Avançado -> Conexão:

Desmarque "Usar porta 80 e 443 como alternativas para conexões de entrada".

E, conforme indicado abaixo, execute uma reinicialização do IIS quando terminar.

— AltF4_
fonte

2

e lembre-se de reiniciar o IIS após fazer isso

— Ahmed Galal

3

Tentei acessar a Last.fm Rest API por trás de um proxy e recebi este famoso erro.

O servidor cometeu uma violação de protocolo. Section = ResponseStatusLine

Depois de tentar algumas soluções alternativas, apenas esses dois funcionaram para mim

HttpWebRequest HttpRequestObj = WebRequest.Create(BaseUrl) as HttpWebRequest;
HttpRequestObj.ProtocolVersion = HttpVersion.Version10;

e

HttpWebRequest HttpRequestObj = WebRequest.Create(BaseUrl) as HttpWebRequest;
HttpRequestObj.ServicePoint.Expect100Continue = false;

— Nixda
fonte

2

Nenhuma das soluções funcionou para mim, então tive que usar um WebClient em vez de um HttpWebRequest e o problema não existia mais.

Eu precisava usar um CookieContainer, então usei a solução postada por Pavel Savara neste tópico - Usando CookieContainer com a classe WebClient

apenas remova "protegido" desta linha:

contêiner de CookieContainer privado = new CookieContainer ();

— TH Todorov
fonte

2

Uma causa provável desse problema é a configuração do WPAD (Web Proxy Auto Discovery Protocol) na rede. A solicitação HTTP será enviada de forma transparente para um proxy que pode enviar de volta uma resposta que o cliente não aceita ou não está configurado para aceitar. Antes de cortar seu código em bits, verifique se o WPAD não está em execução, especialmente se isso "começou a acontecer" do nada.

— Skrymsli
fonte

2

Meu problema é que liguei para o httpsendpoint com http.

— genérico
fonte

1

A primeira coisa que tentamos foi desabilitar a compactação de conteúdo dinâmico para IIS, que resolveu os erros, mas o erro não foi causado no lado do servidor e apenas um cliente foi afetado por isso.

No lado do cliente, desinstalamos os clientes VPN, redefinimos as configurações da Internet e reinstalamos os clientes VPN. O erro também pode ser causado por antivírus anterior que tinha firewall. Então habilitamos a compressão de conteúdo dinâmico de volta e agora funciona bem como antes.

O erro apareceu no aplicativo personalizado que se conecta a um serviço da web e também no TFS.

— HasanG
fonte

0

No meu caso, o IIS não tinha as permissões necessárias para acessar o caminho ASPX relevante.

Dei ao usuário do IIS permissões para o diretório relevante e tudo estava bem.

— Vaiden
fonte

0

Veja seu código e descubra se você está definindo algum cabeçalho com valor NULL ou vazio.

— Abdul Rauf
fonte

0

Comecei a receber este erro de meus serviços JSON / REST php

Comecei a receber o erro de uploads POST relativamente raros depois de adicionar o ob_start("ob_gzhandler")script GET php acessado com mais frequência

Consigo usar apenas ob_start()e está tudo bem.

— Patrick
fonte