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

J'ai créé un programme, essayé de poster 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?

InformationsquelleAutor manish patel | 2010-03-20

c#httpwebrequest

69

Essayer de mettre cela dans votre app/web.config:
```
<system.net>
    <settings>
        <httpWebRequest useUnsafeHeaderParsing="true" />
    </settings>
</system.net>
```
Si cela ne fonctionne pas, vous pouvez aussi essayer le réglage de la KeepAlive valeur false à la propriété.
- J'ai eu 6 url lancer cette erreur. Réglage useUnsafeHeaderParsing fixe pour un lien, mais que la définition de la directive KeepAlive=false fixe pour l'ensemble des 6.
- Réglage uniquement KeepAlive = false fait des merveilles pour moi.
- La même chose peut être placé à l'intérieur <configuration> balise racine à l'App.copnfig pour les applications non web (par exemple, j'ai fixé application WPF, de cette façon - merci!).
- quelqu'un sait pourquoi cette mesure de sécurité est imposée par IIS? Il a travaillé, mais je ne comprends pas la raison de la restriction sur les valeurs d'en-tête (réglage manuel dans mon cas).
- Il s'agit simplement d'éviter le problème plutôt que de le réparer. Je pense que cela ne devrait pas être la solution par défaut.
- D'accord avec Tobias - vous à éviter le problème. Maintenant, il se peut que le problème est dans un serveur qui vous ne pouvez pas résoudre, et donc l'évitement peut être votre seule option... mais tout de même, soyons clairs à propos de la différence entre éviter une erreur de protocole et le fait de le fixer.
- J'ai eu ce problème une fois, mais le problème a été l'appel devait être fait en utilisant le protocole HTTPS et a été fait à l'aide de HTTP.
- J'obtiens ServerProtocolViolation Erreur. J'ai mis useUnsafeHeaderParsing à true. Maintenant, je suis ArgumetOutOfRangeException: System.Net.Http.HttpResponseMessage..ctor(HttpStatusCode statusCode)
- J'ai eu "Le serveur a commis une violation de protocole d'erreur". L'ajout de useUnsafeHeaderParsing permet de le fixer
InformationsquelleAutor Darin Dimitrov
57

Parfois cette erreur se produit lorsque UserAgent paramètre de la requête est vide (en github.com api dans mon cas).

Le réglage de ce paramètre personnalisé pas une chaîne vide résolu mon problème.
- Ah c'est ce dont j'avais besoin. Merci. Voici un user-agent exemple: stackoverflow.com/a/15144495/891976
- Une ligne rapide pour une utilisation avec WebClient ici stackoverflow.com/a/11841680/4795214
- Merci. Si vous souhaitez requête GitHub via HttpClient ajouter: client.DefaultRequestHeaders.Add("User-Agent", "Anything"); ligne pour les résoudre.
InformationsquelleAutor Ivan Kochurkin
27

Le coupable dans mon cas était de retour d'un No Content réponse, mais la définition d'un corps de la réponse en même temps. Peut cette réponse me rappeler et peut-être d'autres de ne pas retourner un NoContent réponse avec un corps jamais de nouveau.

Ce comportement est cohérent avec 10.2.5 204 Aucun Contenu de la Spécification HTTP qui dit:

La réponse 204 ne DOIT PAS inclure un message du corps, et est donc toujours
résilié par la première ligne vide après les champs d'en-tête.
- Viens de lire cette après j'ai eu la The server committed a protocol violation. Section=ResponseStatusLine d'erreur lors de l'utilisation de WebApi de retour personnalisé NoContent() réponse qui a été l'envoi de No Content dans la réponse pour une étrange raison! Une fois que j'ai pris que le problème a disparu 🙂
- Ce fut aussi mon problème, même si c'était difficile parce que c'était l'appel APRÈS le Pas de Contenu de la réponse qui a été un échec.
- Fixe par retrait someContent de return Request.CreateResponse(HttpStatusCode.NoContent, someContent); +1
InformationsquelleAutor Tobias
10

Une autre possibilité: lorsque l'on fait un POST, le serveur répond avec un 100 continuer dans la mauvaise voie.

Cela a résolu le problème pour moi:
```
request.ServicePoint.Expect100Continue = false;
```
- Cela a fonctionné pour moi lors de l'accès à la MediaFire de l'API.
- Je sais que je suis arrivé en retard, mais que voulez-vous dire par "dans la mauvaise voie"?
InformationsquelleAutor marq
9

Ce qui se passait pour moi quand j'avais Skype en cours d'exécution sur ma machine locale. Dès que j'ai fermé que l'exception s'en alla.

Idée de courtoisie de cette page
- A la même question. S'est avéré être Skype. C'est tellement regrettable que des messages appropriés ne peuvent être fournis.
- vous n'avez pas besoin de fermer Skype, j'ai ajouté une réponse ci-dessous pour montrer comment l'aborder sans fermer Skype.
InformationsquelleAutor Luke
8

Une façon de débogage (et assurez-vous que c'est la violation de protocole qui est à l'origine du problème), est d'utiliser Fiddler Http (Proxy Web) et de voir si la même erreur se produit. Si ça ne marche pas (c'est à dire Fiddler géré le problème pour vous), alors vous devriez être en mesure de le réparer à l'aide de la UseUnsafeHeaderParsing drapeau.

Si vous êtes à la recherche d'un moyen pour définir cette valeur par programmation voir les exemples ici: http://o2platform.wordpress.com/2010/10/20/dealing-with-the-server-committed-a-protocol-violation-sectionresponsestatusline/
- Fiddler est en effet à résoudre le problème que j'ai avec une requête HTTP GET. Peut-on voir ce qui se fait de violon ?
InformationsquelleAutor Dinis Cruz
8

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

Une cause possible de cette erreur est si le serveur utilise un encodage autre que ASCII ou ISO-8859-1 à la sortie de l'en-tête de réponse de la section. La raison d'utiliser des ISO-8859-1 serait si le Response-Phrase contient des caractères latins étendus.

Une autre cause possible de cette erreur est si un serveur web utilise UTF-8 que les sorties de l'ordre des octets de marqueur (BOM). Par exemple, la valeur par défaut de la constante Encoding.UTF8 sorties de la NOMENCLATURE, et il est facile de l'oublier. Les pages web fonctionne correctement dans Firefox et Chrome, mais HttpWebRequest sera de la bombe :). Une solution rapide est de changer le serveur web pour utiliser l'encodage UTF-8 qui n'est pas sortie de la NOMENCLATURE, 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, puis UTF-8 ou un autre encodage pour la réponse).
- C'est la meilleure réponse. Il explique pourquoi le serveur web est défaillante. Merci! (J'ai d'émuler un serveur web avec des sockets en raison de problèmes de déploiement avec HttpListener.)
InformationsquelleAutor Loathing
6

Réglage s'attendent à 100 poursuivre pour faux et la réduction de la prise de temps d'inactivité de deux secondes résolu le problème pour moi
```
ServicePointManager.Expect100Continue = false; 
ServicePointManager. MaxServicePointIdleTime = 2000; 
```
InformationsquelleAutor Prashan Pratap
6

Skype a été la principale cause de mon problème:

Cette erreur se produit généralement lorsque vous avez mis en place Visual Studio pour le débogage d'une application web existante cours d'exécution dans IIS plutôt que par le haut dans ASP.NET de débogage du serveur web. IIS par défaut écoute les requêtes web sur le port 80. Dans ce cas, une autre application est déjà en écoute les requêtes sur le port 80. Généralement, l'application qui pose problème est de Skype, qui, par défaut, prend le relais à l'écoute sur les ports 80 et 443 lors de l'installation. Skype est déjà occupent le port 80. Si IIS est incapable de démarrer.

Pour résoudre le problème, suivez les étapes suivantes:

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 l'a souligné ci-dessous effectuer une réinitialisation des services internet une fois fait.
- et n'oubliez pas de redémarrer IIS après l'avoir fait
InformationsquelleAutor AltF4_
3

J'ai essayé d'accéder à la Dernière.fm API Rest de derrière un proxy et a obtenu cette fameuse erreur.

Le serveur commis une violation de protocole. Section=ResponseStatusLine

Après avoir essayé quelques solutions de contournement, seules ces deux 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;
```
InformationsquelleAutor nixda
2

Aucune des solutions n'a fonctionné pour moi, j'ai donc dû utiliser un client web au lieu d'un HttpWebRequest et la question n'était plus.

J'avais besoin d'utiliser un CookieContainer, j'ai donc utilisé la solution posté par Pavel Savara dans ce fil - À l'aide de CookieContainer avec classe WebClient

seulement supprimer les "protégés" de cette ligne:

private readonly CookieContainer container = new CookieContainer();

InformationsquelleAutor TH Todorov
2

Une cause probable de ce problème est de Découverte Automatique de Proxy Web Protocole WPAD () de configuration sur le réseau. La requête HTTP seront en toute transparence envoyé à un proxy qui peut renvoyer une réponse que le client n'accepte pas ou n'est pas configuré pour accepter. Avant de piratage de votre code de bits, vérifiez que le protocole WPAD n'est pas en jeu, en particulier si cette juste "a commencé" out of the blue.

InformationsquelleAutor Skrymsli
2

Mon problème est que j'ai appelé https point de terminaison avec http.

InformationsquelleAutor gneric
1

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

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

Erreur s'est glissée dans la coutume de l'application qui se connecte à un service web et également à TFS.

InformationsquelleAutor HasanG
0

Dans mon cas, IIS n'ont pas les autorisations nécessaires pour accéder aux ASPX chemin.

J'ai donné de l'IIS de l'utilisateur des autorisations pour le répertoire correspondant et tout allait bien.

InformationsquelleAutor Vaiden
0

Voir votre code et de trouver si vous êtes à la définition de certains d'en-tête avec la valeur NULL ou vide.

InformationsquelleAutor Abdul Rauf
0

J'ai commencé à avoir cette erreur de mon php, JSON/REST services

J'ai commencé à faire l'erreur de relativley rare POST uploads après j'ai ajouté ob_start("ob_gzhandler") le plus souvent accessibles OBTENIR script php

Je suis en mesure d'utiliser seulement ob_start(), et tout va bien.

InformationsquelleAutor Patrick

Vous devez vous connecter pour publier un commentaire.