2011-12-16 3 views
5

Il semble que nginx ne supporte pas bien les requêtes groupées. Mais j'essaie d'obtenir une réponse plus définitive (et actuelle). J'ai un client faisant une demande SOAP à un serveur à partir d'un client Java qui définit l'en-tête Transfer-Encoding: chunked. Tout fonctionne bien quand je me connecte directement à mon application sur Tomcat. Mais quand je mets nginx entre eux, alors les choses se cassent.Comment faire une requête en chunked via nginx

Pour ajouter quelques détails: Je travaille avec CloudFoundry. J'utilise Micro Cloud Foundry pour confirmer que les choses fonctionnent comme prévu en l'absence de nginx. Mais mon exigence est d'utiliser cloudfoundry.com, donc je n'ai pas la possibilité de contourner nginx là.

This question and answer dit que c'est peut-être ma seule solution de contournement: http://wiki.nginx.org/NginxHttpChunkinModule. Mais cette solution de contournement n'est pas disponible, car je ne peux pas modifier la configuration sur cloudfoundry.com.

This question ressemble également, mais il couvre en fait l'inverse de cette exigence. Il couvre les réponses fragmentées plutôt que les requêtes segmentées.

Alors, que diriez-vous des changements sur le client pour contourner ce problème? Est-il possible d'envoyer à la fois Transfer-Encoding: chunked et Content-Length: 123 en tant qu'en-têtes? Cette zone est nouvelle pour moi, mais il semble que des projets comme Apache HttpComponents définissent la longueur ou la segmentation, mais pas les deux. Le point de découpage est que vous n'avez pas besoin de connaître la longueur lorsque la demande commence. Pourrais-je dire à mon client d'utiliser HTTP/1.0 et de bien jouer avec nginx sans découper? Y a-t-il d'autres idées de solutions de rechange que j'oublie?

Répondre

4

J'ai recueilli des réponses à toutes les parties de cette question. Base nginx ne supporte pas les requêtes segmentées (comme l'a confirmé Alexander!).

Nginx peut prendre en charge la requête fragmentée en utilisant NginXHttpCunkinModule (comme ma question le mentionne). Mieux: ce module est passé du statut bêta à la qualité de production il y a plus de 18 mois. Meilleur: J'ai parlé avec des membres de l'équipe d'ingénierie de CloudFoundry lors d'un récent meetup; ils confirment qu'il est prévu d'ajouter ce module à leur version de nginx. Problème résolu. (Bien, il est entièrement résolu à long terme, mais nous n'avons pas de date précise pour savoir à quoi s'attendre.)

Par conséquent, une solution à court terme serait bien aussi. J'en ai trouvé un. Répondre à ma question adressée à Alexander: Il n'est pas possible d'envoyer "Content-Length" avec des messages groupés. C'est vraiment le but des messages groupés: vous commencez à les envoyer avant que vous ayez le contenu complet, donc vous ne pouvez pas connaître la longueur pour le moment. Donc, son idée d'éviter les requêtes groupées est correcte. Mais pour être plus pratique, je dirais: "Utilisez HTTP/1.0 plutôt que HTTP/1.1." Cela a pour effet de ne pas envoyer de messages fragmentés. Nous avons été en mesure de patcher temporairement notre client pour tester cette idée. Ça a marché. Mais nous ne prévoyons pas de déployer un patch public. Il semble contreproductif de faire en sorte que tout le monde utilise un protocole vieux de dix ans (et une bibliothèque cliente non prise en charge depuis dix ans!) Pour résoudre le problème dans cette situation. Au lieu de cela, je vais utiliser le client piraté en cas de besoin, je vais envoyer un e-mail si les autres en ont besoin, et nous attendrons que CloudFoundry soit mis à jour pour HttpChunkin et HTTP/1,1.

2

Nginx ne supporte en effet pas les requêtes groupées. Il retournera 411 Content Length required en l'absence de en-tête.

Puisque vous contrôlez votre code client, je suppose que le seul choix est d'éviter d'utiliser des requêtes segmentées et de spécifier explicitement Content-Length.

+0

Est-il possible d'envoyer à la fois Transfer-Encoding: chunked et Content-Length: 123 comme en-têtes? Est-ce commun? – mdahlman