web-dev-qa-db-fra.com

Erreur lors de l'analyse de l'en-tête de la requête HTTP

J'essaie d'envoyer une requête POST du navigateur à mon serveur (hôte local). Mon URL de demande est:

 http://localhost:8080/myPath/myServlet?requestData={  .......//Json String......};

requestData est une chaîne json (j'utilise GSON à cette fin.) Tout fonctionne correctement jusqu'à ce que les données de la chaîne json dépassent une limite particulière. Dites, j'envoie un tableau d'objets dans la chaîne json. Si le nombre d'objets dans la liste dépasse 67, l'erreur suivante s'affiche:

 AM org.Apache.coyote.http11.AbstractHttp11Processor process
 INFO: Error parsing HTTP request header
 Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level.

Pourquoi cela est-il ainsi? Je suis totalement confus. Pourquoi cela se produit-il et que faut-il faire pour résoudre ce problème? Je veux comprendre la raison derrière tout cela, car je ne comprends pas qu'après un certain nombre d'objets, il cesse soudainement de fonctionner et je reçois le message d'erreur suivant .

Merci. 

javahttpservlets
6
user3686864

J'avais un problème similaire: j'envoyais une demande POST (à l'aide du plug-in RESTClient pour Firefox) avec des données dans le corps de la demande et recevais le même message.

Dans mon cas, cela est dû au fait que j'essayais d'utiliser le protocole HTTPS dans une instance locale de Tomcat dans laquelle HTTPS n'était pas configuré.

4
nkatsar

Il semble que vous n'utilisiez pas POST correctement. Bien que vous utilisiez POST, vous envoyez JSON en tant que paramètre de requête qui correspond au style GET. Lorsque vous utilisez POST, vous devez envoyer le contenu sous forme de requête body . Dans ce cas, aucune limite de taille raisonnable n'existe. 

4
AlexR

Dans mon cas, le problème était dû à des problèmes de sécurité. J'ai utilisé csfr pour l'authentification et tous mes formulaires de publication devraient avoir une entrée avec _csrf.

<input type="hidden" name="${_csrf.parameterName}" value="${_csrf.token}"/>
1
Daria

Je m'excuse de ne pas répondre aux questions sérieusement avant.

1.Peut-être causé par des caractères spéciaux.Vous pouvez obtenir des détails à partir de cette URL https://bz.Apache.org/bugzilla/show_bug.cgi?id=60594

résolvez-le par:

encodeURIComponent(JSON.stringify(data))

ou changez votre version de Tomcat à 7.0.67 ou à une version inférieure . Selon l'opinion des développeurs, les développeurs de Tomcat des versions suivantes définissent l'option permettant d'autoriser |，{，}. Get detail http://Tomcat.Apache.org /Tomcat-8.0-doc/config/systemprops.html#Other

La nouvelle variable d'environnement sera incluse dans: - tronc à partir de la version.M18

  • 8.5.x à partir de 8.5.12

  • 8.0.x à partir de 8.0.42

  • 7.0.x pour 7.0.76 et après2.

Une autre raison peut-être que l'en-tête de requête est trop volumineux. Vous pouvez résoudre ce problème en modifiant le server.xml.

<Connector port="8080" maxHttpHeaderSize="8192" maxThreads="150" 
    minSpareThreads="25" maxSpareThreads="75" enableLookups="false"
    redirectPort="8443" acceptCount="100" connectionTimeout="20000" 
    disableUploadTimeout="true" />

J'espère que ça marche pour toi!

1
轩加振

J'ai corrigé cela en passant un en-tête supplémentaire

connexion: close , avec la demande.

Pourriez-vous s'il vous plaît essayer de me faire savoir si cela fonctionne pour vous.

0
Manish Singh

IMHO le problème de l'analyse des en-têtes peut être causé par de nombreuses raisons .

Dans mon cas, cela était dû au fait que le XML suivant a été passé:

<soapenv:Header/>

L'élément d'en-tête vide a été généré par SoapUI . Après la suppression du <soapenv:Header/> du XML de WS, tout s'est bien passé.

0
Rudy Vissers