HTTP Ungültige Anforderung (Anforderungsheader zu lang) in CLM

Dieser Artikel hilft Ihnen, das Problem zu beheben, bei dem im CLM-Portal ein http-fehlerhafter Anforderungsfehler (Hypertext Transfer Protocol) auftritt.

Ursprüngliche Produktversion:   Internetinformationsdienste
Ursprüngliche KB-Nummer:   955585

Problembeschreibung

Sie können nicht alle Vorgänge im CLM-Portal ausführen, möglicherweise tritt das folgende Problem auf:

• Wenn benutzerfreundliche HTTP-Fehlermeldungen in Internet Explorer aktiviert sind, werden HTTP 400-Fehler als Reaktion auf Webanforderungen zurückgegeben, die an den Internetinformationsdienste (IIS)-Server gesendet werden.

• Wenn benutzerfreundliche HTTP-Fehlermeldungen in Internet Explorer deaktiviert sind, wird die folgende Fehlermeldung an den Benutzer zurückgegeben:

  Ungültige Anforderung (Anforderungsheader zu lang)

Ursache

Die HTTP-Anforderung, die an den IIS-Server gesendet wird, verfügt über einen Anforderungsheader, der die zulässige Länge des Anforderungsheaders überschreitet, die auf dem IIS-Server konfiguriert ist. Insbesondere enthält der Autorisierungsheader ein großes Kerberos-Authentifizierungsticket. Das Kerberos-Ticket ist so groß, da der Benutzer Mitglied vieler Gruppen in Active Directory ist.

Aus Sicherheitsgründen lehnt die HTTP.sys-Komponente auf dem IIS-Server die eingehende HTTP-Anforderung ab, da sie die konfigurierten Größenbeschränkungen überschreitet.

Lösung

Konfigurieren Sie die HTTP-Registrierungsschlüssel MaxFieldLength MaxRequestBytes und auf dem IIS-Server, um größere Anforderungsheadergrößen zu ermöglichen.

Wichtig

Das Ändern dieser Registrierungsschlüssel wird als äußerst gefährlich betrachtet. Das Erhöhen dieser Schlüsselwerte führt dazu, dass HTTP.sys mehr Arbeitsspeicher nutzen und die Sicherheitslücke gegenüber böswilligen Angriffen erhöhen kann. Wenn das Ändern dieser Schlüssel Ihre einzige Option ist, legen Sie ihre Werte nicht größer als erforderlich fest. Informationen dazu, wie groß die Anforderungsheader sind und welcher Wert zum Festlegen der Registrierungsschlüssel erforderlich ist, finden Sie weiter unten in diesem Artikel.

• Weitere Informationen zu den HTTP.sys Registrierungsschlüsseln für IIS finden Sie unter Http.sys Registrierungseinstellungen für IIS.

• Weitere Informationen zur HTTP.sys Fehlerprotokollierung finden Sie unter Fehlerprotokollierung in HTTP-APIs.

Ermitteln der Größe von HTTP-Anforderungen

Um die tatsächliche Größe der HTTP-Anforderung zu ermitteln, kann es hilfreich sein, eine Netzwerküberwachungsüberwachung zu verwenden. Mit dieser Ablaufverfolgung können wir die Größe der HTTP-Anforderung berechnen und mit der Einstellung auf dem IIS-Server vergleichen.

Es ist auch hilfreich, informationen im HTTP.sys Fehlerprotokoll zu suchen.

Lage: %windir%\system32\logfiles\HTTPERR\httperrX.log

Der Schlüssel zum Beheben dieses problems besteht darin, zu zeigen, dass CLM versucht, eine HTTP-Anforderung an den Server zu senden, die größer als der Standardwert von 16k oder größer als die benutzerdefinierte Einstellung in ihrer MaxFieldLength und MaxRequestBytes ist. Verwenden Sie dazu eine Kombination aus:

1. Ablaufverfolgung des Netzwerkmonitors
2. Durchsuchen des http.sys Fehlerprotokolls, das sich in %windir%\system32\logfiles\HTTPERR\httperrX.log befindet.

Beispieleintrag aus "httperrX.log":

Datumszeit c-ip c-port s-ip s-port cs-version cs-method cs-uri sc-status s-siteid s-reason s-queuename 2007-04-12 07:37:51 10.201.25.27 1682 10.248.10.65 80 HTTP/1.1 GET /clm 400 - RequestLength

Netmon

Führen Sie in der NetMon-Ablaufverfolgung die folgenden Schritte aus, um zu ermitteln, wie groß die HTTP-Anforderung ist:

1. Suchen Des Frames, der eine HTTP-Anweisung sendet Get

2. Fügen Sie den TCP-Wert (Transmission Control Protocol) für jeden Frame aus der HTTP-Anweisung hinzu, Len bis der Get IIS-Server eine ACK zurückgibt.

   Dies ist die Größe der HTTP-Anforderung.

   Beispiel:

   28209 19:13:04.041 53.906250 Client Server HTTP: Request, GET /CLM/content/sm/requests/SubscriberPrintDocuments.aspx
   28210 19:13:04.041 53.906250 Client Server HTTP: HTTP Payload
   28210 19:13:04.041 53.906250 Client Server HTTP: HTTP Payload
   28211 19:13:04.041 53.906250 Client Server HTTP: HTTP Payload
   28212 19:13:04.041 53.906250 Client Server HTTP: HTTP Payload
   28213 19:13:04.041 53.906250 Client Server HTTP: HTTP Payload
   28214 19:13:04.041 53.906250 Client Server HTTP: HTTP Payload
   28215 19:13:04.041 53.906250 Client Server HTTP: HTTP Payload
   28216 19:13:04.041 53.906250 Client Server HTTP: HTTP Payload
   28217 19:13:04.041 53.906250 Client Server HTTP: HTTP Payload
   28218 19:13:04.041 53.906250 Client Server HTTP: HTTP Payload
   28219 19:13:04.041 53.906250 Client Server HTTP: HTTP Payload
   28220 19:13:04.041 53.906250 Client Server HTTP: HTTP Payload

   Jede der obigen Elemente weist eine Detailzeile auf, die der folgenden ähnelt:

   Tcp: Flags=.... A..., SrcPort=3281, DstPort=HTTP(80), Len=1460 , Seq=3225410770 - 3225412230, Ack=1377780890, Win=33580 (Skalierungsfaktor 0) = 0

   In diesem Beispiel liegt die GRÖßE der HTTP-Anforderung bei etwa 17000, was mehr als dem Standardmäßigen Maximum entspricht.

Wireshark

1. Suchen Sie den Frame, der die HTTP-Anweisung sendet. Get
2. Zeigen Sie die Registerkarte am unteren Rand des WireShark-Bildschirms mit dem Titel "Reassembled TCP" an, und die Zahl daneben ist die Größe der erneut zusammengesetzten HTTP-Anforderung.