Le serveur a commis une violation de protocole. Section = ERREUR ResponseStatusLine


115

J'ai créé un programme, essayé de publier une chaîne sur un site et j'obtiens cette erreur:

"Le serveur a commis une violation de protocole. Section = ResponseStatusLine"

après cette ligne de code:

gResponse = (HttpWebResponse)gRequest.GetResponse(); 

Comment puis-je corriger cette exception?

Réponses:


71

Essayez de mettre ceci dans votre app / web.config:

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

Si cela ne fonctionne pas, vous pouvez également essayer de définir la KeepAlivepropriété sur false.


3
J'ai eu 6 URL lançant cette erreur. La configuration de useUnsafeHeaderParsing l'a corrigé pour un lien, mais la configuration de KeepAlive = false l'a corrigé pour tous les 6.
David Hammond

3
La même chose peut être placée dans la balise racine <configuration> sur App.copnfig pour les applications non Web (par exemple, j'ai corrigé l'application WPF de cette façon - merci!).
Yury Schkatula

quelqu'un sait pourquoi cette mesure de sécurité est imposée par IIS? Cela a fonctionné, mais je ne comprends pas la raison de la restriction sur les valeurs d'en-tête (les définir manuellement dans mon cas).
emran

26
Il s'agit simplement d'éviter le problème plutôt que de le résoudre. Je pense que cela ne devrait pas être la solution par défaut.
Tobias

4
D'accord avec Tobias - vous évitez le problème. Maintenant, il se peut que le problème soit dans un serveur que vous ne pouvez pas résoudre, et donc l'évitement peut être votre seule option ... mais soyons tout de même clairs sur la différence entre éviter une erreur de protocole et la réparer.
metaforge

58

Parfois, cette erreur se produit lorsque UserAgent paramètre de demande est vide (dans l'api github.com dans mon cas).

La définition de ce paramètre sur une chaîne personnalisée non vide a résolu mon problème.


5
Ah c'est ce dont j'avais besoin. Merci. Voici un exemple d'utilisateur-agent: stackoverflow.com/a/15144495/891976
David Ruhmann

Une ligne rapide à utiliser avec WebClientici stackoverflow.com/a/11841680/4795214

5
Merci. Si vous voulez interroger GitHub via HttpClient add: client.DefaultRequestHeaders.Add("User-Agent", "Anything"); line pour corriger.
Cihan Yakar

32

Le coupable dans mon cas était de renvoyer une No Contentréponse mais de définir un corps de réponse en même temps. Que cette réponse me rappelle, et peut-être aux autres, de ne pas renvoyer une NoContentréponse avec un corps .

Ce comportement est cohérent avec 10.2.5 204 No Content de la spécification HTTP qui dit:

La réponse 204 NE DOIT PAS inclure un corps de message, et est donc toujours terminée par la première ligne vide après les champs d'en-tête.


Lisez simplement ceci après avoir reçu l' The server committed a protocol violation. Section=ResponseStatusLine erreur lors de l'utilisation de WebApi pour renvoyer une NoContent()réponse personnalisée qui envoyait No Contentla réponse pour une raison étrange! Une fois que j'ai éliminé cela, le problème a disparu :)
Intrepid

2
C'était aussi mon problème, même si c'était délicat car c'était l'appel APRÈS la réponse No Content qui échouait.
mdickin

Correction en supprimant someContentde return Request.CreateResponse(HttpStatusCode.NoContent, someContent); +1
snippetkid

12

Autre possibilité: lors d'un POST, le serveur répond par un 100 continue de manière incorrecte.

Cela a résolu le problème pour moi:

request.ServicePoint.Expect100Continue = false;

Cela a fonctionné pour moi lors de l'accès à l'API MediaFire.
AlexPi

3
Je sais que j'arrive en retard, mais qu'entendez-vous par «d'une manière incorrecte»?
kuskmen

1
Pour tous ceux qui utilisent HttpClient , ce qui suit a fonctionné pour moi:var http = new HttpClient(); http.DefaultRequestHeaders.ExpectContinue = false;
user2444499

9

Cela se produisait pour moi lorsque Skype fonctionnait sur ma machine locale. Dès que j'ai fermé, l'exception a disparu.

Idée gracieuseté de cette page


Eu le même problème. S'est avéré être Skype. C'est tellement malheureux que les messages appropriés ne peuvent pas être fournis.
jordan koskei

vous n'avez pas réellement besoin de fermer Skype, j'ai ajouté une réponse ci-dessous pour montrer comment y faire face sans fermer Skype.
AltF4_

8

Une façon de déboguer cela (et de vous assurer que c'est la violation de protocole qui est à l'origine du problème) consiste à utiliser Fiddler (proxy Web Http) et à voir si la même erreur se produit. Si ce n'est pas le cas (c'est-à-dire que Fiddler a géré le problème pour vous), vous devriez être en mesure de le résoudre à l'aide de l'indicateur UseUnsafeHeaderParsing.

Si vous cherchez un moyen de définir cette valeur par programme, consultez les exemples ici: http://o2platform.wordpress.com/2010/10/20/dealing-with-the-server-committed-a-protocol-violation-sectionresponsestatusline /


Fiddler résout en effet le problème que j'ai avec une requête GET HTTP. Pouvons-nous voir ce que fait le violoneux?
Olivier MATROT

8

De nombreuses solutions parlent d'une solution de contournement, mais pas de la cause réelle de l'erreur.

Une cause possible de cette erreur est si le serveur Web utilise un codage autre que ASCIIou ISO-8859-1pour afficher la section de réponse d'en-tête. La raison à utiliser ISO-8859-1serait si le Response-Phrasecontient des caractères latins étendus.

Une autre cause possible de cette erreur est si un serveur Web utilise UTF-8qui génère le marqueur d'ordre d'octet (BOM). Par exemple, la constante par défautEncoding.UTF8 génère la nomenclature, et il est facile de l'oublier. Les pages Web fonctionneront correctement dans Firefox et Chrome, mais HttpWebRequestbombarderont :). Une solution rapide consiste à changer le serveur Web pour utiliser le codage UTF-8 qui ne génère pas la nomenclature, par exemple new UTF8Encoding(false)(ce qui est correct tant que le serveur Response-Phrasene contient que des caractères ASCII, mais il devrait vraiment utiliser ASCIIou ISO-8859-1pour les en-têtes, puis UTF-8ou un autre encodage pour la réponse).


C'est la meilleure réponse. Cela explique pourquoi le serveur Web se comporte mal. Merci! (Je dois émuler un serveur Web avec des sockets en raison de problèmes de déploiement avec HttpListener.)
Andrew Rondeau

6

La définition de expect 100 continue à false et la réduction du temps d'inactivité du socket à deux secondes a résolu le problème pour moi

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

6

Skype était la principale cause de mon problème:

Cette erreur se produit généralement lorsque vous avez configuré Visual Studio pour déboguer une application Web existante s'exécutant dans IIS plutôt que dans ASP.NET intégré serveur Web de débogage intégré. IIS par défaut écoute les requêtes Web sur le port 80. Dans ce cas, une autre application écoute déjà les requêtes sur le port 80. En général, l'application incriminée est Skype, qui par défaut prend en charge l'écoute sur les ports 80 et 443 une fois installée. Skype occupe déjà le port 80. IIS ne peut donc pas démarrer.

Pour résoudre le problème, procédez comme suit:

Skype -> Outils -> Options -> Avancé -> Connexion:

Décochez "Utiliser les ports 80 et 443 comme alternatives pour les connexions entrantes".

Et comme indiqué ci-dessous, effectuez une réinitialisation IIS une fois terminé.


2
et n'oubliez pas de redémarrer IIS après cela
Ahmed Galal

3

J'ai essayé d'accéder à l'API Last.fm Rest derrière un proxy et j'ai obtenu cette fameuse erreur.

Le serveur a commis une violation de protocole. Section = ResponseStatusLine

Après avoir essayé quelques solutions de contournement, seuls ces deux ont fonctionné pour moi

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

et

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

2

Aucune des solutions n'a fonctionné pour moi, j'ai donc dû utiliser un WebClient au lieu d'un HttpWebRequest et le problème n'était plus.

J'avais besoin d'utiliser un CookieContainer, j'ai donc utilisé la solution publiée par Pavel Savara dans ce fil - Utilisation de CookieContainer avec la classe WebClient

supprimez simplement "protected" de cette ligne:

private readonly CookieContainer container = new CookieContainer ();


2

Une cause probable de ce problème est la configuration du protocole WPAD (Web Proxy Auto Discovery Protocol) sur le réseau. La requête HTTP sera envoyée de manière transparente à un proxy qui peut renvoyer une réponse que le client n'acceptera pas ou n'est pas configuré pour accepter. Avant de pirater votre code en bits, vérifiez que WPAD n'est pas en jeu, en particulier si cela «a commencé à se produire» à l'improviste.



1

La première chose que nous avons essayée était de désactiver la compression de contenu dynamique pour IIS, ce qui a résolu les erreurs, mais l'erreur n'a pas été causée côté serveur et un seul client a été affecté par cela.

Du côté client, nous avons désinstallé les clients VPN, réinitialisé les paramètres Internet, puis réinstallé les clients VPN. L'erreur pourrait également être causée par un antivirus précédent doté d'un pare-feu. Ensuite, nous avons réactivé la compression de contenu dynamique et maintenant cela fonctionne bien comme avant.

Une erreur est apparue dans l'application personnalisée qui se connecte à un service Web et également à TFS.


0

Dans mon cas, l'IIS n'avait pas les autorisations nécessaires pour accéder au chemin ASPX pertinent.

J'ai donné à l'utilisateur IIS les autorisations d'accès au répertoire concerné et tout allait bien.


0

Consultez votre code et trouvez si vous définissez un en-tête avec une valeur NULL ou vide.


0

J'ai commencé à recevoir cette erreur de mes services php JSON / REST

J'ai commencé à recevoir l'erreur des téléchargements POST relativement rares après avoir ajouté ob_start("ob_gzhandler")au script GET php le plus fréquemment consulté

Je suis capable d'utiliser juste ob_start(), et tout va bien.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.