Le serveur a commis une violation du protocole. Section=Reponsestatusline ERROR

essayez de mettre ceci dans votre application/web.config:

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

si cela ne fonctionne pas, vous pouvez également essayer de définir la propriété KeepAlive à false.

parfois, cette erreur se produit lorsque le paramètre de requête UserAgent est vide (en github.com api in my case).

paramétrer ce paramètre à la chaîne custom not empty a résolu mon problème.

dans mon cas, le coupable retournait une réponse No Content , mais définissait en même temps un corps de réponse. Puisse cette réponse me rappeler et peut-être d'autres de ne plus jamais retourner une NoContent réponse avec un corps .

ce comportement est compatible avec 10.2.5 204 pas de contenu de la spécification HTTP qui dit:

la réponse 204 ne doit pas inclure un corps de message, et donc est toujours résilié par la première ligne vide après les champs d'en-tête.

une autre possibilité: en faisant un POST, le serveur répond avec un 100 continue d'une manière incorrecte.

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

request.ServicePoint.Expect100Continue = false;

cela se passait pour moi quand J'ai eu Skype fonctionnant sur ma machine locale. Dès que j'ai fermé, l'exception a disparu.

idée courtoisie de cette page

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 encodage autre que ASCII ou ISO-8859-1 pour afficher la section de réponse de l'en-tête. La raison d'utiliser ISO-8859-1 serait que le Response-Phrase contient des caractères latins étendus.

une autre cause possible de cette erreur est si un serveur web utilise UTF-8 qui l'ordre des octets de marqueur (BOM). Par exemple, la constante par défaut Encoding.UTF8 affiche le BOM, et il est facile de l'oublier. Les pages web fonctionneront correctement dans Firefox et Chrome, mais HttpWebRequest bombera :). Une solution rapide est de changer le serveur web pour utiliser L'encodage UTF-8 qui ne produit pas le BOM, par exemple new UTF8Encoding(false) (qui est OK aussi longtemps que le Response-Phrase ne contient que des caractères ASCII, mais vraiment il devrait utiliser ASCII ou ISO-8859-1 pour les en-têtes, et puis UTF-8 ou un autre encodage pour la réponse).

une façon de déboguer ceci (et de s'assurer que c'est la violation du protocole qui cause le problème), est d'utiliser Fiddler (mandataire Web Http) et de voir si la même erreur se produit. Si ce n'est pas le cas (c.-à-d. que Fiddler a géré le problème pour vous), alors vous devriez être en mesure de le corriger en utilisant le drapeau UseUnsafeHeaderParsing.

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

réglage expect 100 continuer à false et la réduction du temps de ralenti socket à deux secondes résolu le problème pour moi

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

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 tournant dans IIS plutôt que dans le ASP.NET debug Web server. IIS par défaut écoute les requêtes web sur le port 80. Dans ce cas, une autre application est déjà à l'écoute des requêtes sur le port 80. Typiquement, L'application incriminée est Skype, qui par défaut prend sur écoute sur les ports 80 et 443 une fois installés. Skype occupe déjà le port 80. Donc IIS est incapable de commencer.

pour résoudre le problème suivre les étapes:

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

Décochez la case "Utiliser les ports 80 et 443 comme solution de rechange pour les connexions entrantes".

et comme indiqué ci-dessous effectuer une réinitialisation IIS une fois fait.

j'ai essayé d'accéder au dernier.FM reste API de derrière un proxy et a obtenu cette erreur célèbre.

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

après avoir essayé quelques solutions de rechange, seulement ces deux-là ont travaillé 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;

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

j'avais besoin d'utiliser un CookieContainer, donc j'ai utilisé la solution posté par Pavel Savara dans ce fil - en utilisant CookieContainer avec la classe WebClient

il suffit de supprimer "protégé" de cette ligne:

private readonly CookieContainer container = new CookieContainer();

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

côté client, nous avons désinstallé les clients VPN, réinitialisé les paramètres internet et réinstallé les clients VPN. L'erreur pourrait aussi être causée par un antivirus précédent qui avait un pare-feu. Ensuite, nous avons permis la compression de contenu dynamique et maintenant il fonctionne comme avant.

erreur apparu dans l'application personnalisée qui se connecte à un service web et aussi à TFS.

mon problème est que j'ai appelé https endoipint avec http .

dans mon cas, L'IIS n'avait pas les permissions nécessaires pour accéder au chemin ASPX concerné.

j'ai donné les permissions de l'utilisateur IIS au répertoire approprié et tout allait bien.

voir votre code et trouver si vous définissez un en-tête avec une valeur nulle ou vide.

j'ai commencé à obtenir cette erreur à partir de mes services php JSON / REST

j'ai commencé à obtenir l'erreur de relativley rare post uploads après que j'ai ajouté ob_start("ob_gzhandler") au script le plus fréquemment consulté GET php

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

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