Pourquoi "Content-Length: 0" dans les requêtes POST?

Question

Un client envoie parfois des requêtes POST avec Content-Length: 0 lors de la soumission d'un formulaire (de 10 à plus de 40 champs).

Nous l'avons testé avec les différents navigateurs et à partir de différents endroits, mais ne pouvait pas reproduire l'erreur. Le client est à l'aide d'Internet Explorer 7 et un proxy.

Nous leur avons demandé de laisser leurs administrateur système voir dans le problème de leur côté. L'exécution de certains tests sans le proxy, etc..

Dans le temps (une demi-année plus tard et toujours pas de réponse) je suis curieux de savoir si quelqu'un d'autre connaît des problèmes similaires avec un Content-Length: 0 de la demande. Peut-être à l'intérieur de certaines réseau Windows avec une procuration spéciale pour les grandes entreprises.

Est-il un problème connu avec Internet Explorer 7? Avec un système d'enchères? Le réseau de Windows lui-même?

Google a montré quelque chose dans le contexte de NTLM (et) d'authentification, mais nous ne sommes pas à l'aide de ce dans l'application web. C'est peut-être dans la façon dont le proxy fonctionne dans le réseau du client avec les ouvertures de session Windows? (Je ne suis pas un expert Windows. Juste deviner.)

Je n'ai pas plus d'informations sur l'infrastructure.

Mise à JOUR: En décembre 2010, il a été possible d'informer un administrateur à propos de ce, incl. liens de réponses ici. Le Contact a été à cause d'un autre problème, qui est causé par le proxy, trop. Pas de commentaires depuis. Et les messages d'erreur sont toujours là. Je ris à m'empêcher de pleurer.

Mise à JOUR 2: Ce problème existe depuis la mi-2008. Tous les quelques mois, le client est en colère et veut qu'il soit résolu rapidement. Nous les envoyer tous les anciens e-mails de nouveau et lui demander de communiquer avec leurs administrateurs, soit de le réparer ou d'exécuter certains tests supplémentaires. En décembre 2010, nous avons été en mesure d'envoyer de l'information à 1 administrateur. Pas de retour. Le problème n'est pas résolu et nous ne savons pas si ils ont même essayé. Et en Mai 2011, le client écrit à nouveau et veut que ce soit corrigé. La même personne qui a toutes les informations depuis 2008.

Merci pour toutes les réponses. Vous avez aidé beaucoup de gens, comme je peux le voir dans certains commentaires ici. Dommage que le monde réel est ce grotesque pour moi.

Mise à JOUR 3: Mai 2012 et je me demandais pourquoi nous n'avons pas reçu une autre demande pour la résoudre (voir mise à JOUR 2). Regardé dans le protocole d'erreurs, qui ne signale que cette seule erreur à chaque fois que c'est arrivé (environ 15 par jour). Il s'est arrêté à la fin de janvier 2012. Personne n'a dit quoi que ce soit. Ils ont dû faire quelque chose avec leur réseau. Tout est OK maintenant. À partir de l'été 2008 à janvier 2012. Dommage que je ne peux pas vous dire ce qu'ils ont fait.

Answer 1

Internet Explorer n'envoie pas de champs de formulaire si elles sont validées à partir d'un site authentifié (NTLM) à un non-authentifié site (anonyme).

Ce qui est caractéristique pour le challenge-réponse situations (NTLM ou Kerberos sites web sécurisés) où c'est à dire peut s'attendre à ce que le premier POST de demande immédiatement conduit à une erreur HTTP 401 Authentification Requise réponse (qui inclut un défi), et seulement la deuxième requête POST (qui inclut la réponse à la provocation) sera réellement accepté. Dans ces situations, IE ne le télécharger éventuellement le grand corps de la requête avec la première demande pour des raisons de performances. Grâce à EricLaw pour l'affichage que peu d'informations dans les commentaires.

Ce problème se produit chaque fois qu'un HTTP POST est fait d'un NTLM authentifié (c'est à dire Intranet) de la page à un non-authentifié (c'est à dire Internet) de la page, ou si le non-authentifié page fait partie d'un jeu de cadres, où la page de jeu de cadres est authentifié.

La solution de contournement est d'utiliser une requête GET, comme la méthode du formulaire, ou pour s'assurer que la non-authentifié page s'ouvre dans une nouvelle onglet/fenêtre (favoris/cible du lien) sans une partie authentifié jeu de cadres. Dès que le modèle d'authentification pour l'ensemble de la fenêtre est cohérent, c'est à dire va commencer à envoyer le formulaire contenu nouveau.

---

• Certainement liées: http://www.websina.com/bugzero/kb/browser-ie.html
• Peut-être liés: KB923155
• Explication complète: IEInternals Blog – Challenge-Réponse d'Authentification et de Longueur Nulle Postes

Answer 2

C'est facile à reproduire avec MS-IE et une authentification NTLM filtre sur le côté serveur. J'ai le même problème avec JCIFS (1.2.), struts 1. et MS-IE 6/7 sur XP SP2. Il a finalement été résolu. Il existe plusieurs solutions pour le faire.

1. formulaire de changement de méthode de POST (struts réglage par défaut) pour l'OBTENIR. Pour la plupart des pages avec de petites formes, il fonctionne bien. Malheureusement, j'ai peut-être plus de 50 dossiers à envoyer dans le flux HTTP de retour à côté serveur. IE a un GET URL limite 2038 Octets (pas de paramètre de longueur, mais l'ensemble de la longueur de l'URL). C'est donc une solution de rechange rapide, mais pas pour moi.

2. envoyer un OBTENIR avant la fin de l'action en cours d'exécution. Cela a été recommandé dans MS-KO. Mon projet a de nombreuses héritage des procédures et je ne voudrais pas prendre le risque, au bon moment. Je n'ai jamais essayé ce parce qu'il a encore besoin de quelques extra authentification de traitement lors de l'OBTENIR est reçu par le filtre de calque d'après ma compréhension à partir de MS-KO et je ne voudrais pas de modifier le comportement avec les autres navigateurs, par exemple Firefox, Opera.

3. détecter si le message a été envoyé avec zéro content-length (vous pouvez l'obtenir à partir de propriétés d'en-tête de hachage de la structure avec votre cadre). Si oui, déclencher une authentification NTLM cycle par obtenir le code de challenge de DC ou de cache et d'attendre une réponse NTLM. Lorsque le NTLM type2 msg est reçu et que la session est encore valide, vous n'avez pas vraiment besoin d'authentifier l'utilisateur, mais juste à l'avant à l'action prévue si le POST content-length n'est pas zéro. BTW, ce qui permettrait de renforcer le réseau de transports. Afin de vérifier votre de vie du cache de réglage de l'heure et de la session SMB soTimeOut de configuration avant d'appliquer le changement plz. Ou, plus simple, vous pouvez tout simplement envoyer un 401-non autorisé statut de MS-IE et le navigateur doit envoyer une requête POST avec des données en réponse.

4. MS-KO a fourni un hot-fix avec KO-923155 (je ne pouvais pas poster plus d'un lien à cause d'une faible réputation nombre :{ ) , mais il ne semble pas travailler. Quelqu'un poste une pratique hot-fix ici? Merci :) Voici un lien pour référence, http://www.websina.com/bugzero/kb/browser-ie.html

Answer 3

Il ya une bonne chance que le problème est que le serveur proxy entre implémente le protocole HTTP 1.0.

En HTTP 1.0, vous devez utiliser le Contenu de Longueur de champ d'en-tête: (Voir la section 10.4 ici)

Un Content-Length valide est requis sur tous HTTP/1.0 requêtes POST. Un HTTP/1.0 serveur doit répondre avec un 400 (bad request) message si il ne peut pas déterminer la longueur de la demande contenu du message.

La demande va dans le proxy HTTP 1.1 et n'a donc pas besoin d'utiliser le Contenu de Longueur de champ d'en-tête. La Longueur du Contenu de l'en-tête est utilisé habituellement, mais pas toujours. Voir l'extrait suivant de le HTTP 1.1 RFC S. 14.13.

Les Applications DOIVENT utiliser ce champ pour indiquer le transfert de la longueur de la message du corps, sauf si cela est interdit par les règles de la section 4.4. Tout le Contenu de Longueur supérieure ou égal à zéro est une valeur valide.

La Section 4.4 décrit comment déterminer la longueur d'un message-corps si un Content-Length n'est pas donné.

Si le serveur proxy ne pas voir le Contenu de l'en-tête de Longueur, qu'il suppose, est absolument nécessaire en HTTP 1.0 si il y a un corps. Donc, il suppose que 0, de sorte que la demande finira par atteindre le serveur. Rappelez-vous le proxy ne connaissent pas les règles de la HTTP 1.1 spec, de sorte qu'il ne sait pas comment gérer la situation quand il n'y a pas de Contenu en-tête de Longueur.

Êtes-vous sûr à 100% votre demande en précisant le Contenu de l'en-tête de Longueur? Si c'est à l'aide d'un autre moyen tel que défini à la section 4.4, car il pense que le serveur est de 1,1 (parce qu'il ne connaît pas le 1.0 proxy entre les deux), puis vous aurez votre problème décrit.

Peut-être que vous pouvez utiliser HTTP GET au lieu de contourner le problème.

Answer 4

C'est un problème connu pour Internet explorer 6, mais pas pour le 7, que je sache. Vous pouvez installer ce correctif pour la IE6 KB831167 correctif.

Vous pouvez lire plus à ce sujet ici.

Quelques questions pour vous:

• Savez-vous quel type de proxy?
• Savez-vous si il existe un corps envoyées dans la requête?
• Il arrive systématiquement à chaque fois? Ou seulement parfois?
• Est-il binaire des données envoyées dans la requête? Peut-être que les données commence par un \0 et que le proxy a un bug avec les données binaires.