Paramètres POST manquants avec les serveurs proxy

Question

Nous rencontrons un comportement étrange avec notre application Web. Certaines requêtes POST n'ont pas de corps http, alors qu'elles le devraient. content-length est 0. Il n'y a aucun paramètre post. Nous avons suivi le trafic réseau sur notre loadbalancer et nous constatons que nous n'obtenons aucun corps de requête avec certaines de nos requêtes POST.

Toutes les requêtes POST rompues ont en commun qu'elles arrivent via un serveur proxy.

Nous avons déjà trouvé cette question sur le SO: Why "Content-Length: 0" in POST requests?

Nous utilisons maintenant un cadre échapper javascript routine et il aide un peu. Il semble que le taux d'erreur diminue. Mais nous avons toujours des requêtes POST sans données qui ne devraient jamais arriver dans notre webapp. Ces demandes ne proviennent pas de hackers ou de semblables.

Souvent, nous avons vu webwasher comme un proxy. Mais la plupart du temps, nous ne voyons pas quel proxy est utilisé.

Dans ce PDF, nous avons vu un commentaire sur l'absence de paramètres POST avec Webwasher

WebWasher - Transparent Authentication Guide

Notes sur quelques Pitfalls

Notez qu'il ya des pièges qui doivent être prises en compte lors de la mise en up authentication transparent:

Les requêtes POST échouent si le serveur ICAP envoie une redirection au serveur d'authentification. Cela n'affecte cependant que le renouvellement du mappage car, pour le navigateur, la requête a abouti et le corps POST ne sera plus envoyé après la redirection finale.

Nous aimerions savoir s'il existe une autre solution que d'utiliser uniquement GET au lieu de POST. Nous aimerions également savoir si d'autres sites ont eu des problèmes avec des données POST manquantes et quelle conclusion ils ont faite.

Existe-t-il d'autres raisons pour lesquelles les données POST ne sont pas envoyées?

Answer 1

J'ai rencontré des problèmes avec le serveur proxy de Microsoft ne fonctionnant pas bien avec les requêtes Web.

J'ai dû forcer HTTP/1.0 et définir la propriété KeepAlive sur false.

Il y a quelque chose dans le fonctionnement de l'authentification NTLM qui provoque l'envoi sporadique du corps.

Je l'ai ajouté à un grand nombre de mes demandes web

protected override WebRequest GetWebRequest(Uri uri) 
{ 
    HttpWebRequest webRequest = (HttpWebRequest) base.GetWebRequest(uri); 

    webRequest.KeepAlive = false; 
    webRequest.ProtocolVersion=HttpVersion.Version10; 
    return webRequest; 
} 

Hope this helps!

Answer 2

Pas ceux qui se conforment à la spec:

Certaines méthodes HTTP DOIVENT provoquer un cache pour invalider une entité. ... POST

(HTTP/s applications ne doivent pas cache des réponses à une requête POST '1.0 états SPEC).

Mais il y a beaucoup de code mal écrit là-bas.

Quels en-têtes incluez-vous dans les réponses aux POST sur les URL?

Answer 3

Pas vraiment une réponse, je suppose, mais je suis arrivé ici parce que nous avions un problème similaire. Au départ, nous pensions que c'était dû au fait que les clients étaient mobiles, car c'était un thème commun, mais nous avons maintenant réalisé que le dénominateur commun est les procurations.

Nous élevons maintenant un http 400 quand cela arrive.

Voici quelques-uns des proxies, nous avons eu des problèmes avec. leur affichage pour diriger le googler occasionnel ici:

• 1.1 ACISA02S, 1.1 abc:3328 (squid/2.6.STABLE21)
• 1.1 ipcop00.cat.local:8000 (squid/2.6.STABLE21)
• 1.1 PRXTGLSRV01
• 1.1 ISA