it-swarm.com.de

Warum "Content-Length: 0" in POST Wünsche?

Ein Kunde sendet manchmal POST -Anfragen mit Content-Length: 0, wenn er ein Formular sendet (10 bis über 40 Felder).

Wir haben es mit verschiedenen Browsern und von verschiedenen Standorten aus getestet, konnten den Fehler jedoch nicht reproduzieren. Der Kunde verwendet Internet Explorer 7 und einen Proxy.

Wir haben sie gebeten, ihren Systemadministrator von ihrer Seite in das Problem einweisen zu lassen. Ausführen einiger Tests ohne Proxy usw.

In der Zwischenzeit (ein halbes Jahr später und immer noch keine Antwort) bin ich neugierig, ob jemand anderes Probleme mit einer Content-Length: 0-Anfrage kennt. Vielleicht von innerhalb eines Windows-Netzwerks mit einem speziellen Proxy für große Unternehmen.

Gibt es ein bekanntes Problem mit Internet Explorer 7? Mit einem Proxy-System? Das Windows-Netzwerk selbst?

Google hat nur etwas im Zusammenhang mit der NTLM-Authentifizierung (und einer solchen Authentifizierung) gezeigt, dies wird jedoch nicht in der Webanwendung verwendet. Vielleicht ist es so, dass der Proxy mit Windows-Anmeldungen im Kundennetzwerk arbeitet? (Ich bin kein Windows-Experte. Nur raten.)

Ich habe keine weiteren Informationen über die Infrastruktur.

UPDATE: Im Dezember 2010 war es möglich, einen Administrator darüber zu informieren. Links von den Antworten hier. Der Kontakt war auf ein anderes Problem zurückzuführen, das ebenfalls durch den Proxy verursacht wurde. Kein Feedback seitdem. Und die Fehlermeldungen sind immer noch da. Ich lache, um mich am Weinen zu hindern.

UPDATE 2: Dieses Problem besteht seit Mitte 2008. Alle paar Monate ist der Kunde verärgert und möchte, dass es so schnell wie möglich behoben wird. Wir senden ihnen alle alten E-Mails erneut und bitten sie, sich an ihre Administratoren zu wenden, um sie entweder zu reparieren oder einige weitere Tests durchzuführen. Im Dezember 2010 konnten wir einige Informationen an einen Administrator senden. Kein Feedback. Das Problem ist nicht behoben und wir wissen nicht, ob sie es überhaupt versucht haben. Und im Mai 2011 schreibt der Kunde erneut und möchte, dass dies behoben wird. Dieselbe Person, die seit 2008 über alle Informationen verfügt.

Danke für alle Antworten. Sie haben vielen Menschen geholfen, wie ich an einigen Kommentaren hier sehen kann. Schade, dass die reale Welt für mich so grotesk ist.

UPDATE 3: May 2012 und ich wunderte mich, warum wir keine weitere Aufforderung zur Behebung dieses Problems erhalten hatten (siehe UPDATE 2). Schauen Sie sich das Fehlerprotokoll an, das diesen Fehler nur bei jedem Auftreten (etwa 15 am Tag) meldet. Es hörte Ende Januar 2012 auf. Niemand sagte etwas. Sie müssen etwas mit ihrem Netzwerk gemacht haben. Alles ist jetzt ok. Von Sommer 2008 bis Januar 2012. Zu schade, dass ich Ihnen nicht sagen kann, was sie getan haben.

UPDATE 4: September 2015. Die Website musste einige Daten erheben und an die Hauptseite des Kunden übermitteln. Es gab eine API mit einem Konto. Wann immer es ein Problem gab, kontaktierten sie uns, auch wenn das Problem eindeutig auf der anderen Seite lag. Seit einigen Wochen können wir ihnen die Daten nicht mehr senden. Das Konto ist nicht mehr verfügbar. Sie hatten einen Relaunch und ich kann die Seiten nicht mehr finden, auf denen die Daten unserer Website verwendet wurden. Der Fehlerbericht wird nicht beantwortet und niemand beschwert sich. Ich denke, sie haben dieses Projekt gerade beendet.

UPDATE 5: März 2017. Die API funktionierte im Sommer 2015 nicht mehr. Der Kunde scheint weiterhin für die Website zu zahlen und greift noch im Februar 2017 darauf zu. Sie erstellen oder aktualisieren keine Daten mehr, so dass dieser Fehler nach dem mysteriösen Fix vom Januar 2012 wahrscheinlich nicht wieder auftaucht. Dies wäre jedoch das Problem einer anderen Person. Ich gehe weg.

50
stesch

Internet Explorer sendet keine Formularfelder, wenn sie von einer authentifizierten Site (NTLM) an eine nicht authentifizierte Site (anonym) gesendet werden. 

Dies ist eine Funktion für Situationen mit herausfordernden Antworten (NTLM- oder Kerberos-gesicherte Websites), bei denen IE erwarten kann, dass die erste POST -Anfrage sofort zu einer HTTP 401 Authentication Required Antwort führt (die eine Herausforderung enthält), und nur die zweite POST - Anforderung (die die Antwort auf die Herausforderung enthält) wird tatsächlich akzeptiert. In diesen Situationen lädt IE den möglicherweise großen Anfragetext bei der ersten Anforderung aus Leistungsgründen nicht hoch. Vielen Dank an EricLaw für die Veröffentlichung dieser Information in den Kommentaren.

Dieses Verhalten tritt jedes Mal auf, wenn ein HTTP POST von einer NTLM-authentifizierten Seite (z. B. Intranet) auf eine nicht authentifizierte Seite (z. B. Internet) erstellt wird oder wenn die nicht authentifizierte Seite Teil eines Framesets ist, in dem das Frameset enthalten ist Seite ist authentifiziert.

Sie können dieses Problem umgehen, indem Sie entweder eine GET-Anforderung als Formularmethode verwenden oder sicherstellen, dass die nicht authentifizierte Seite in einem neuen Tab/Fenster (Favorit/Link-Ziel) ohne ein teilweise authentifiziertes Frameset geöffnet wird. Sobald das Authentifizierungsmodell für das gesamte Fenster konsistent ist, sendet IE erneut den Formularinhalt.


40
Tomalak

Dies ist mit MS-IE und einem NTLM-Authentifizierungsfilter auf der Serverseite leicht zu reproduzieren. Ich habe das gleiche Problem mit JCIFS (1.2 .), Streben 1. und MS-IE 6/7 auf XP-SP2. Es wurde endlich behoben. Es gibt mehrere Problemumgehungen. 

  1. Ändern Sie die Formularmethode von POST (Struts-Standardeinstellung) in GET. Bei den meisten Seiten mit kleinen Formularen funktioniert es gut. Leider habe ich möglicherweise mehr als 50 Datensätze, um den HTTP-Stream wieder an die Serverseite zu senden. IE hat ein GET-URL-Limit von 2038 Bytes (nicht die Parameterlänge, sondern die gesamte URL-Länge). Das ist also eine schnelle Abhilfe, aber für mich nicht anwendbar.

  2. senden Sie ein GET, bevor POST Aktion ausgeführt wird. Dies wurde in MS-KB empfohlen. Mein Projekt hat viele alte Verfahren und ich würde das Risiko nicht zur richtigen Zeit eingehen. Ich habe dies noch nie ausprobiert, da es nach meinem Verständnis von MS-KB immer noch eine zusätzliche Authentifizierungsverarbeitung benötigt, wenn GET von der Filterschicht empfangen wird, und ich möchte das Verhalten mit anderen Browsern nicht ändern, z. Firefox, Opera.

  3. feststellen, ob POST mit einer Inhaltslänge von null gesendet wurde (möglicherweise erhalten Sie sie von der Header-Eigenschaften-Hash-Struktur Ihres Frameworks). Wenn dies der Fall ist, lösen Sie einen NTLM-Authentifizierungszyklus aus, indem Sie den Challenge-Code von DC oder cache abrufen und eine NTLM-Antwort erwarten. Wenn die NTLM-Typ2-Nachricht empfangen wird und die Sitzung noch gültig ist, müssen Sie den Benutzer nicht wirklich authentifizieren, sondern nur an die erwartete Aktion weiterleiten, wenn POST Inhaltslänge nicht Null ist. Übrigens, dies würde den Netzwerkverkehr erhöhen. Überprüfen Sie daher die Einstellung für die Cache-Lebensdauer und SMB session soTimeOut-Konfiguration, bevor Sie die Änderung in plz .. übernehmen. Oder einfacher: Sie können einfach einen 401-unautorisierten Status an MS-IE senden, und der Browser sendet back POST Anfrage mit Antwortdaten.

  4. MS-KB hat einen Hot-Fix mit KB-923155 bereitgestellt (ich konnte aufgrund einer niedrigen Rufnummer nicht mehr als einen Link posten: {), aber es scheint nicht zu funktionieren. Würde hier jemand einen funktionsfähigen Hot-Fix posten? Danke :) Hier ist ein Link als Referenz, http://www.websina.com/bugzero/kb/browser-ie.html

14
maxwu

Wir haben einen Kunden in unserem System, der genau das gleiche Problem hat. Wir haben es auf den Proxy/die Firewall festgelegt. Microsofts IAS. Es entfernt den POST -Körper und sendet die Inhaltslänge: 0. Wir können jedoch nicht viel tun, um Abhilfe zu schaffen, und wollen GET-Anforderungen nicht verwenden, da dies Benutzernamen/Kennwörter usw. für die URL-Zeichenfolge freigibt. Es gibt fast 7.000 Benutzer in unserem System und nur einer mit dem Problem ... auch nur einer, der Microsoft IAS verwendet, also muss es so sein.

6
Scott

Es besteht eine gute Chance, dass das Problem darin besteht, dass der Proxy-Server dazwischen HTTP 1.0 implementiert.

In HTTP 1.0 müssen Sie das Headerfeld Content-Length verwenden: ( Siehe Abschnitt 10.4 hier )

Für .__ ist eine gültige Inhaltslänge erforderlich. alle HTTP/1.0 POST -Anfragen. Ein Der HTTP/1.0-Server sollte mit einem .__ antworten. 400 (falsche Anforderung), wenn dies nicht möglich ist Bestimmen Sie die Länge der Anforderung Inhalt der Nachricht.

Die an den Proxy gerichtete Anforderung lautet HTTP 1.1 und muss daher nicht das Headerfeld Content-Length verwenden. Der Content-Length-Header wird normalerweise verwendet, jedoch nicht immer. Siehe den folgenden Auszug aus dem HTTP 1.1 RFC S. 14.13

Anwendungen SOLLTE dieses Feld für .__ verwenden. geben Sie die Übertragungslänge von .__ an. Nachrichtentext, es sei denn, dies ist durch die Regeln in Abschnitt verboten 4.4 . Jede Inhaltslänge größer als oder gleich Null ist ein gültiger Wert.

Abschnitt 4.4 beschreibt, wie .__ ermittelt wird. die Länge eines Nachrichtentexts, wenn a Content-Length wird nicht angegeben.

Der Proxyserver sieht daher den Content-Length-Header nicht. Dies wird vorausgesetzt, dass er in HTTP 1.0 unbedingt erforderlich ist, wenn ein Body vorhanden ist. Es geht also von 0 aus, damit die Anfrage schließlich den Server erreicht. Denken Sie daran, dass der Proxy die Regeln der HTTP 1.1-Spezifikation nicht kennt, und er weiß nicht, wie er mit der Situation umgehen soll, wenn es keinen Content-Length-Header gibt. 

Sind Sie zu 100% sicher, dass Ihre Anfrage den Content-Length-Header angibt? Wenn andere Mittel verwendet werden, wie in Abschnitt 4.4 definiert, da der Server der Meinung ist, dass der Server 1.1 ist (da er den 1.0-Proxy nicht kennt), wird das beschriebene Problem auftreten. 

Vielleicht können Sie stattdessen HTTP GET verwenden, um das Problem zu umgehen. 

4
Brian R. Bondy

Dies ist ein bekanntes Problem für Internet Explorer 6, aber nicht für 7, das ich kenne. Sie können diesen Fix für den IE6 KB831167 Fix installieren.

Sie können lesen Sie hier mehr darüber

Einige Fragen an Sie:

  • Wissen Sie welche Art von Proxy?
  • Wissen Sie, ob in der Anfrage eine tatsächliche Leiche gesendet wurde?
  • Kommt es jedes Mal konstant vor? Oder nur manchmal?
  • Werden in der Anfrage binäre Daten gesendet? Möglicherweise beginnen die Daten mit einem\0 und der Proxy hat einen Fehler mit binären Daten. 
3
Brian R. Bondy

Wenn der Benutzer einen ISA -Proxy durchläuft, der die NTLM-Authentifizierung verwendet, klingt dies wie dieses Problem, für das eine Lösung bereitgestellt wurde (ein Patch für den ISA -Proxy).

http://support.Microsoft.com/kb/942638
POST-Anforderungen, die nicht über einen POST - Body verfügen, können an einen Webserver gesendet werden, der in ISA Server 2006 veröffentlicht ist

2
GStephens

Sind Sie sicher, dass diese Anfragen von einem "Kunden" stammen?

Ich hatte dieses Problem schon einmal mit Bots. Manchmal werden Websites nach Formularen für "Kontaktaufnahme" durchsucht, indem leere POST - Anforderungen gesendet werden, die auf dem Aktions-URI in FORM-Tags basieren, die sie beim Crawlen finden.

1
JasonTrue

Vorhandensein und mögliche Werte des ContentLength-Headers in HTTP werden im HTTP-RFC (von 1/1 angenommen) beschrieben:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13

In HTTP sollte es gesendet werden, wenn die Länge der Nachricht vor der Übertragung bestimmt werden kann

Siehe auch:

Wenn eine Nachricht mit einem .__ empfangen wird. Übertragscodierungs-Headerfeld und ein Content-Length-Headerfeld Letzteres MUSS ignoriert werden.http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4

Vielleicht trägt Ihre Nachricht einen Transfer-Encoding-Header?

Später editieren: Bitte beachten Sie, dass "SOLLTE", wie sie im RFC verwendet wird, sehr wichtig ist und nicht "MUST" entspricht:

3. SOLLTE Dieses Wort oder das Adjektiv "EMPFOHLEN" bedeuten, dass Es kann unter bestimmten Umständen triftige Gründe geben, ein .__ zu ignorieren. bestimmten Punkt, aber die vollen Auswirkungen müssen verstanden werden und sorgfältig abgewogen, bevor Sie einen anderen Kurs wählen. Ref: http://www.ietf.org/rfc/rfc2119.txt

1
diciu

curl sendet PUT/POST-Anforderungen mit Content-Length: 0, wenn sie für die Verwendung von HTTP-Proxy konfiguriert ist. Es ist ein Trick, um die erforderliche Pufferung im Falle einer ersten nicht autorisierten PUT/POST-Anforderung an den Proxy zu überwinden. Bei GET/HEAD-Anforderungen wiederholt curl die Abfrage einfach. Das Schema für PUT/POST ist wie folgt:

  1. Senden Sie die erste PUT/POST-Anforderung mit Content-Length auf 0.

  2. Antwort bekommen Der HTTP-Statuscode 407 bedeutet, dass die Proxy-Autorisierung verwendet werden muss. Bereiten Sie die Header für die Proxy-Authentifizierung für die Sendeanforderung vor.

  3. Senden Sie die Anforderung erneut mit gefüllten Kopfzeilen für die Proxy-Authentifizierung und reale Daten an POST/PUT.

0
user1641854

Wir hatten einen Kunden, der dieselbe Website im anonymen Modus und im NTLM-Modus (an verschiedenen Ports) verwendete. Wir fanden heraus, dass die 401 in unserem Fall mit der Riverbed Steelhead-Anwendung in Verbindung stand, die für die HTTP-Optimierung verwendet wurde. Das erste Signal in diese Richtung war ein X-RBT-Optimized-By-Header. Das Problem war die Funktion "Gratuitous 401":

Diese Funktion kann sowohl für jede Anforderung als auch für jede Verbindung verwendet werden Die Authentifizierung ist jedoch am effektivsten, wenn sie mit Per-Request verwendet wird Authentifizierung. Bei der Authentifizierung pro Anforderung muss jede Anforderung .__ sein. authentifiziert am Server, bevor der Server die Einwände gegen den Kunden. Die meisten Browser zwischenspeichern jedoch nicht den Server Antwort, die eine Authentifizierung erfordert, und daher wird eine verschwendet Hin- und Rückfahrt für jede GET-Anfrage. Bei Gratuitous 401 ist die clientseitige Die Steelhead-Appliance speichert die Serverantwort und, wenn der Client sendet die GET-Anforderung ohne Authentifizierungsheader. Antworten Sie lokal mit der Meldung "401 Unauthorized" und speichern Sie somit eine Rundreise. Beachten Sie, dass das HTTP-Modul nicht am .__ beteiligt ist. tatsächliche Authentifizierung selbst. Was das HTTP-Modul tut, ist zu informieren der Client, für den der Server eine Authentifizierung erfordert, ohne dass es ist eine Rundreise zu verschwenden.

0
wdk

Ich hatte auch ein Problem, bei dem Anforderungen des IE 11-Browsers eines Kunden Content-Length: 0 hatten und nicht den erwarteten POST Inhalt enthielten. Wenn der Kunde Firefox oder Chrome verwendet hat, wurde der erwartete Inhalt in die Anforderung aufgenommen.

Ich habe herausgefunden, dass der Kunde eine HTTP-URL anstelle einer HTTPS-URL verwendet hat (z. B. http://..., nicht https://...) und unsere Anwendung HSTS verwendet. Es scheint, dass in IE 11 ein Fehler aufgetreten ist, der besagt, dass der Inhalt der Anforderung verloren geht, wenn eine Anforderung aufgrund von HSTS auf HTTPS aktualisiert wird.

Wenn der Kunde die URL zu https://... korrigierte, wurde der Inhalt in die Anforderung POST aufgenommen und das Problem gelöst.

Ich habe in dieser Phase nicht weiter untersucht, ob es sich tatsächlich um einen Fehler in IE 11 handelt.

0
matthewrwilton

Microsofts Hotfix für KB821814 kann Content-Length auf 0 setzen:

Der in diesem Artikel beschriebene Hotfix implementiert eine Codeänderung in Wininet.dll in:

  • Erkennen Sie die RESET-Bedingung bei einer Anforderung von POST.
  • Speichern Sie die zu buchenden Daten.
  • Wiederholen Sie die Anforderung POST mit einer auf 0 gesetzten Inhaltslänge. Dadurch wird das Zurücksetzen verhindert und der Authentifizierungsvorgang kann abgeschlossen werden.
  • Wiederholen Sie die ursprüngliche Anforderung von POST.
0
user151236

Google zeigt dies auch als IE (einige Versionen, sowieso) an, nachdem eine https-Verbindung das Keepalive-Timeout erreicht und sich wieder mit dem Server verbindet. Die Lösung scheint den Server so zu konfigurieren, dass keepalive für IE unter https nicht verwendet wird.

0
ysth