Il server ha commesso una violazione del protocollo. Sezione = ResponseStatusLine ERROR


115

Ho creato un programma, ho provato a inserire una stringa su un sito e ottengo questo errore:

"Il server ha commesso una violazione del protocollo. Sezione = ResponseStatusLine"

dopo questa riga di codice:

gResponse = (HttpWebResponse)gRequest.GetResponse(); 

Come posso correggere questa eccezione?

Risposte:


71

Prova a metterlo nella tua app / web.config:

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

Se questo non funziona, puoi anche provare a impostare la KeepAliveproprietà su false.


3
Ho avuto 6 URL che lanciano questo errore. L'impostazione di useUnsafeHeaderParsing lo ha corretto per un collegamento, ma l'impostazione KeepAlive = false lo ha risolto per tutti i 6.
David Hammond

3
Lo stesso può essere inserito all'interno del tag radice <configuration> in App.copnfig per applicazioni non Web (ad esempio, ho corretto l'app WPF in questo modo, grazie!).
Yury Schkatula

qualcuno sa perché questa misura di sicurezza è imposta da IIS? Ha funzionato, ma non capisco il motivo della restrizione sui valori di intestazione (impostandoli manualmente nel mio caso).
emran

26
Questo è semplicemente evitare il problema piuttosto che risolverlo effettivamente. Penso che questa non dovrebbe essere la soluzione predefinita.
Tobias

4
D'accordo con Tobias: stai evitando il problema. Ora può darsi che il problema sia in un server che non puoi risolvere, e quindi l'evitamento potrebbe essere la tua unica opzione ... ma comunque, chiariamo la differenza tra evitare un errore di protocollo e risolverlo effettivamente.
metaforge

58

A volte questo errore si verifica quando il UserAgentparametro di richiesta è vuoto (nell'api github.com nel mio caso).

L'impostazione di questo parametro su una stringa personalizzata non vuota ha risolto il mio problema.


5
Ah questo è ciò di cui avevo bisogno. Grazie. Ecco un esempio di user-agent: stackoverflow.com/a/15144495/891976
David Ruhmann

Un rapido linea per l'uso con WebClientqui stackoverflow.com/a/11841680/4795214

5
Grazie. Se vuoi interrogare GitHub tramite HttpClient add: client.DefaultRequestHeaders.Add("User-Agent", "Anything"); line per la correzione.
Cihan Yakar

32

Il colpevole nel mio caso stava restituendo una No Contentrisposta ma allo stesso tempo definendo un corpo di risposta. Possa questa risposta ricordare a me e forse ad altri di non restituireNoContent mai più una risposta con un corpo .

Questo comportamento è coerente con 10.2.5 204 Nessun contenuto della specifica HTTP che dice:

La risposta 204 NON DEVE includere il corpo del messaggio e quindi è sempre terminata dalla prima riga vuota dopo i campi di intestazione.


Basta leggere questo dopo aver ricevuto l' The server committed a protocol violation. Section=ResponseStatusLine errore durante l'utilizzo di WebApi per restituire una NoContent()risposta personalizzata che stava inviando No Contentla risposta per qualche strano motivo! Una volta che l'ho tolto, il problema è andato via :)
Intrepid

2
Questo era anche il mio problema, sebbene fosse complicato perché era la chiamata DOPO la risposta No Content che stava fallendo.
mdickin

Risolto rimuovendo someContentda return Request.CreateResponse(HttpStatusCode.NoContent, someContent); +1
snippetkid

12

Un'altra possibilità: quando si esegue un POST, il server risponde con un 100 continue in modo errato.

Questo ha risolto il problema per me:

request.ServicePoint.Expect100Continue = false;

Questo ha funzionato per me durante l'accesso all'API MediaFire.
AlexPi

3
So che arrivo in ritardo ma cosa intendi con "in modo errato"?
kuskmen

1
Per chiunque utilizzi HttpClient , per me ha funzionato quanto segue:var http = new HttpClient(); http.DefaultRequestHeaders.ExpectContinue = false;
user2444499

9

Questo stava accadendo per me quando avevo Skype in esecuzione sulla mia macchina locale. Non appena ho chiuso l'eccezione è andata via.

Idea per gentile concessione di questa pagina


Ha avuto lo stesso problema. Si è rivelato essere Skype. È così sfortunato che non possano essere forniti messaggi adeguati.
jordan koskei

in realtà non è necessario chiudere Skype, ho aggiunto una risposta di seguito per mostrare come affrontarlo senza chiudere Skype.
AltF4_

8

Un modo per eseguire il debug di ciò (e per assicurarsi che sia la violazione del protocollo a causare il problema), è utilizzare Fiddler (Http Web Proxy) e vedere se si verifica lo stesso errore. In caso contrario (ovvero Fiddler ha gestito il problema per te), dovresti essere in grado di risolverlo utilizzando il flag UseUnsafeHeaderParsing.

Se stai cercando un modo per impostare questo valore in modo programmatico, guarda gli esempi qui: http://o2platform.wordpress.com/2010/10/20/dealing-with-the-server-committed-a-protocol-violation-sectionresponsestatusline /


Fiddler sta effettivamente risolvendo il problema che ho con una richiesta HTTP GET. Possiamo vedere cosa fa il violinista?
Olivier MATROT

8

Molte soluzioni parlano di una soluzione alternativa, ma non della causa effettiva dell'errore.

Una possibile causa di questo errore è se il server web utilizza una codifica diversa da ASCIIo ISO-8859-1per visualizzare la sezione di risposta dell'intestazione. Il motivo per utilizzare ISO-8859-1sarebbe se il Response-Phrasecontiene caratteri latini estesi.

Un'altra possibile causa di questo errore è se un server web utilizza l' UTF-8output del byte-order-marker (BOM). Ad esempio, la costante predefinita Encoding.UTF8restituisce la distinta componenti ed è facile dimenticarla. Le pagine web funzioneranno correttamente in Firefox e Chrome, ma HttpWebRequestbombarderanno :). Una soluzione rapida è cambiare il server web in modo che utilizzi la codifica UTF-8 che non restituisce la distinta componenti, ad esempio new UTF8Encoding(false)(che è OK fintanto che Response-Phrasecontiene solo caratteri ASCII, ma in realtà dovrebbe usare ASCIIo ISO-8859-1per le intestazioni, e quindi UTF-8o qualche altra codifica per la risposta).


Questa è la migliore risposta. Spiega perché il server web si comporta male. Grazie! (Devo emulare un server web con socket a causa di problemi di distribuzione con HttpListener.)
Andrew Rondeau

6

L'impostazione prevede che 100 continui a false e la riduzione del tempo di inattività del socket a due secondi ha risolto il problema per me

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

6

Skype è stata la causa principale del mio problema:

Questo errore si verifica in genere quando è stato configurato Visual Studio per eseguire il debug di un'applicazione Web esistente in esecuzione in IIS anziché nel server Web di debug ASP.NET integrato. IIS per impostazione predefinita ascolta le richieste Web sulla porta 80. In questo caso, un'altra applicazione è già in ascolto per le richieste sulla porta 80. In genere, l'applicazione incriminata è Skype, che per impostazione predefinita assume l'ascolto sulle porte 80 e 443 una volta installata. Skype sta già occupando la porta 80. Quindi IIS non è in grado di avviarsi.

Per risolvere il problema, segui i passaggi:

Skype -> Strumenti -> Opzioni -> Avanzate -> Connessione:

Deseleziona "Usa le porte 80 e 443 come alternative per le connessioni in entrata".

E come indicato di seguito, eseguire un ripristino IIS una volta fatto.


2
e ricorda di riavviare IIS dopo averlo fatto
Ahmed Galal

3

Ho provato ad accedere all'API Rest di Last.fm da dietro un proxy e ho ricevuto questo famoso errore.

Il server ha commesso una violazione del protocollo. Sezione = ResponseStatusLine

Dopo aver provato alcune soluzioni alternative, solo questi due hanno funzionato per me

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

e

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

2

Nessuna delle soluzioni ha funzionato per me, quindi ho dovuto utilizzare un WebClient invece di un HttpWebRequest e il problema non c'era più.

Avevo bisogno di utilizzare un CookieContainer, quindi ho utilizzato la soluzione pubblicata da Pavel Savara in questo thread - Utilizzo di CookieContainer con la classe WebClient

rimuovi semplicemente "protected" da questa riga:

contenitore cookieContainer privato in sola lettura = new CookieContainer ();


2

Una causa probabile di questo problema è la configurazione WPAD (Web Proxy Auto Discovery Protocol) sulla rete. La richiesta HTTP verrà inviata in modo trasparente a un proxy che può restituire una risposta che il client non accetterà o non è configurato per accettare. Prima di hackerare il tuo codice in bit, controlla che WPAD non sia in gioco, in particolare se questo "ha iniziato ad accadere" dal nulla.


2

Il mio problema era che ho chiamato httpsendpoint con http.


1

La prima cosa che abbiamo provato è stata disabilitare la compressione del contenuto dinamico per IIS, che ha risolto gli errori ma l'errore non è stato causato dal lato server e solo un client è stato interessato da questo.

Sul lato client abbiamo disinstallato i client VPN, ripristinato le impostazioni Internet e quindi reinstallato i client VPN. L'errore potrebbe anche essere causato da un precedente antivirus dotato di firewall. Quindi abbiamo abilitato la compressione del contenuto dinamico e ora funziona bene come prima.

Errore nell'applicazione personalizzata che si connette a un servizio Web e anche a TFS.


0

Nel mio caso l'IIS non disponeva delle autorizzazioni necessarie per accedere al relativo percorso ASPX.

Ho concesso le autorizzazioni utente IIS alla directory pertinente e tutto è andato bene.


0

Guarda il tuo codice e trova se stai impostando un'intestazione con NULL o un valore vuoto.


0

Ho iniziato a ricevere questo errore dai miei servizi PHP JSON / REST

Ho iniziato a ricevere l'errore da caricamenti POST relativamente rari dopo aver aggiunto ob_start("ob_gzhandler")allo script GET php a cui si accede più di frequente

Sono in grado di usare solo ob_start(), e va tutto bene.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.