Skip to main content

Das Sicherheitstool UrlScan

Mit UrlScan 2.5 können Sie festlegen, welche HTTP-Anfragen von IIS (Internet Information Services) bearbeitet werden dürfen und welche nicht. Angriffe auf IIS-Server über bestimmte Anfragetypen lassen sich so schon im Vorfeld unterbinden. Sie können UrlScan auf Servern mit IIS 4.0 oder höher installieren.

Hinweis: Microsoft hat inzwischen UrlScan 3.0 veröffentlicht. Die neue Version erweitert UrlScan 2.5 um Funktionen wie die Möglichkeit, auf Grundlage von Abfrage-Strings zu filtern, was bei der Abwehr von SQL-Injection-Angriffen eingesetzt werden kann

.Auf dieser Seite

Neue Features in UrlScan 2.5Neue Features in UrlScan 2.5
Einsatz von UrlScan 2.5 mit IIS 6.0Einsatz von UrlScan 2.5 mit IIS 6.0
UrlScan 2.5 installierenUrlScan 2.5 installieren
Häufig gestellte FragenHäufig gestellte Fragen

Neue Features in UrlScan 2.5

Microsoft hat UrlScan in der Version 2.5 zusammen mit einem neuen Installationsprogramm veröffentlicht, mit dem eine saubere Installation auf Systemen mit IIS 4.0 oder höher möglich ist.

Wichtig:UrlScan verhindert viele Arten von Angriffen. Es ist jedoch nicht dafür gedacht, Updates und Patches auf dem aktuellen Stand zu halten. Microsoft empfiehlt Ihnen dringend, Sicherheitspatches zu installieren, um Server sicher zu halten und bekannte Sicherheitsprobleme zu beheben.

UrlScan besteht aus den zwei Dateien (UrlScan.dll und UrlScan.ini), die beide in der Datei UrlScan.exe enthalten sind. Mit Version 2.5 erhalten Sie als Administrator noch mehr Kontrolle über die Konfiguration von UrlScan. Die Version stellt Funktionen zur Verfügung, die Ihnen bei der weiteren Absicherung der Server helfen.

Die folgenden Features wurden mit UrlScan 2.5 eingeführt und standen in vorhergehenden Versionen nicht zur Verfügung:

Verzeichnisse für Protokolldateien ändern

UrlScan 2.5 verfügt über die neue Funktion LoggingDirectory. Diese wird verwendet, um den Ordner für die Speicherung von Protokolldateien auszuwählen. Es muss es sich um einen absoluten Pfadnamen handeln (zum Beispiel c:\verzeichnis). Wenn Sie keinen Ordner bestimmen, erstellt UrlScan das Protokoll in dem Ordner, in dem sich die Datei UrlScan.dll befindet.

Lange URLs protokollieren

Die Funktion LogLongUrls wurde hinzugefügt, um die Länge der protokollierten URLs zu erhöhen. In früheren Versionen hat UrlScan jede Zeile im Protokoll nach 1024 Bytes abgeschnitten. Die neue Option erlaubt es, diese Beschränkung auf 128 KB heraufzusetzen. Gültige Werte sind 0 oder 1. Die Voreinstellung ist 0. Dies bedeutet, dass weiterhin nur die ersten 1024 Bytes protokolliert werden. Wenn Sie den Wert auf 1 setzen, protokolliert UrlScan bis zu 128 KB pro Anfrage.

Anfragengröße beschränken

Mit der Funktion RequestLimits können Sie Anfragen an den Server nach deren Größe in Byte einschränken. Die Funktion enthält die folgenden drei Einträge:

  • MaxAllowedContentLength: Maximallänge für Anfragen. Diese Einstellung schützt den Server nicht notwendigerweise davor, mehr Daten zu lesen, als hier angegeben sind. Beispiel: Wenn ein Client eine gestückelte POST-Anfrage sendet, kann UrlScan nicht die Größe der gesamten Anfrage erkennen. Der standardmäßige Wert beträgt ca. 2 GB (2.000.000.000 Byte).

  • MaxUrl: Schränkt die Länge der angefragten URL ein - wobei allerdings nicht die Länge der Abfrage limitiert wird. Wenn Sie UrlScan über den Installer aktualisieren, wird der Standardwert auf 16 KB gesetzt.
    Anmerkung: Wenn Sie die Datei UrlScan.dll manuell aus UrlScan.exe entpacken und die Datei UrlScan.ini daher nicht aktualisiert wird, lautet die Standardeinstellung für diesen Wert 260 Byte. In diesem Fall müssen Sie in die Datei UrlScan.ini den Eintrag MaxUrl = 16384 einfügen.

  • MaxQueryString: Beschränkt die Länge der Abfrage. Der Standardwert beträgt 4 KB. Sie können zusätzlich ein Limit in Byte für einen speziellen Anfrage-Header setzen, indem Sie den einen Eintrag "Max-HEADERNAME" erstellen. Beispiel: Der folgende Eintrag setzt ein Limit von 100 Byte für den Header "Content-Type": Max-Content- Type=100. Wenn Sie für einen Header keine Beschränkung festlegen möchten, verwenden Sie den Wert 0. Beispiel: Max-User-Agent=0. Alle Header, die in diesem Abschnitt nicht angegeben werden, unterliegen ebenfalls keiner Längenbeschränkung.

Zum SeitenanfangZum Seitenanfang

Einsatz von UrlScan 2.5 mit IIS 6.0

Microsoft® Windows Server™ 2003 besitzt eine Vielzahl systemeigener Features, die bei der Absicherung von IIS 6.0-Servern helfen. Als Ergänzung zu den Möglichkeiten von IIS 6.0 stellt UrlScan weitere Funktionen für die Absicherung zur Verfügung. Einige Organisationen haben UrlScan außerdem bereits in die Verwaltungsprozesse ihrer IIS-Server aufgenommen. Wenn Sie die zusätzlichen Features von UrlScan 2.5 verwenden oder Ihre momentane Sicherheitsverwaltung aufrecht erhalten möchten, sollten Sie UrlScan 2.5 zusammen mit IIS 6.0 verwenden.

UrlScan 2.5 ist in IIS 6.0 nicht enthalten. Die systemeigenen Features von IIS 6.0 bieten in den meisten Fallen eine höherwertige oder mindestens gleichwertige Sicherheitsfunktionalität.

Tabelle 1: Vergleich von UrlScan 2.5 und IIS 6.0

Features von UrlScan 2.5Standardmäßige Möglichkeiten von IIS 6.0
DenyExtensions: Diese Funktion wurde in UrlScan zur Verringerung der Angriffoberfläche implementiert. Anhand von Dateierweiterungen verhindert sie, dass bestimmte Anfragen ISAPI- oder CGI-Code ausführen.IIS 6.0 schränkt die Angriffsoberfläche von Servern ein, indem Administratoren definieren können, welcher ISAPI- und CGI-Code ausgeführt werden soll. Das UrlScan-Feature ist somit nicht mehr notwendig.
DenyVerbs: Angreifer können auf Webservern anhand von bestimmten HTTP-Verbs WebDAV-Code aufrufen. Diese Funktion wurde implementiert, um zu verhindern, dass Anfragen WebDAV aufrufen.IIS 6.0 gibt Administratoren die Möglichkeit, WebDAV explizit zu aktivieren oder zu deaktivieren. Da dieser Vorgang den WebDAV-Code direkt betrifft, ist das Feature von UrlScan nicht mehr notwendig.
DenyVerbs: Angreifer können auf Webservern anhand von bestimmten HTTP-Verbs WebDAV-Code aufrufen. Diese Funktion wurde implementiert, um zu verhindern, dass Anfragen WebDAV aufrufen.IIS 6.0 gibt Administratoren die Möglichkeit, WebDAV explizit zu aktivieren oder zu deaktivieren. Da dieser Vorgang den WebDAV-Code direkt betrifft, ist das Feature von UrlScan nicht mehr notwendig.
NormalizeUrlBeforeScan: Mit dieser Funktion können Sie festlegen, ob IIS die vom Client gesendete unbearbeitete URL oder die auf dem Server normalisierte URL verarbeitet.
Anmerkung: Auf Produktivservern ist es nicht empfehlenswert, diesen Wert auf 0 zu setzen. Wenn dieser Wert auf 0 gesetzt ist, müssen alle möglichen Codierungen jedes Zeichens für die Dateierweiterungen und die anderen Tests in der Datei UrlScan.ini spezifiziert werden.
Die in IIS 6.0 enthaltenen Absicherungsmechanismen basieren auf dem erlaubten ausführbaren Code - nicht auf der vom Client angefragten URL. Aus diesem Grund ist die Funktion NormalizeUrlBeforeScan unter IIS 6.0 nicht notwendig.
VerifyNormalization: UrlScan kann unter vielen IIS-Versionen ausgeführt werden. Das Tool, das die URLs verarbeitet, wurde mit späteren Versionen und Service Packs erweitert. Mithilfe dieser Funktion kann UrlScan mögliche Probleme bei der URLVerarbeitung auf nicht gepatchten Systemen erkennen.Die Komponente HTTP.SYS von IIS 6.0 schützt vor URL-Verarbeitungsangriffen.
DenyUrlSequences: Über dieses Feature kann UrlScan Sequenzen entdecken, die in URL-basierten Angriffen verwendet werden.IIS 6.0 muss keine URL-Sequenzen ablehnen. Aufgrund ihres Designs ist IIS 6.0 nicht durch URLSequenzen verwundbar.
AllowDotInPath: Der Lockdown- Mechanismus von UrlScan hängt davon ab, dass in einem frühen Stadium des Verarbeitungsprozesses eine Benachrichtigung über einen Filter erfolgt. Zu diesem Zeitpunkt kann UrlScan allerdings noch nicht genau wissen, wie IIS die URL für PATH_INFO parsen wird. Es besteht die Möglichkeit, dass PATH_INFO die Dateinamenerweiterung der URL verändert. Wenn Sie AllowDotInPath auf den Wert 0 setzen, lehnt UrlScan jede Anfrage mit Dateierweiterungen ab, bei denen ein Punkt im Pfad vorhanden ist.Die Funktion AllowDotInPathist unter IIS 6.0 nicht notwendig, da diese nicht von Benachrichtigungen über Filter abhängig sind.
RemoveServerHeader: Mithilfe dieser Funktion kann UrlScan bei der Antwort an den Client im Response-Header die Identität des Servers ändern oder entfernen.Unter IIS 6.0 ist die Einstellung RemoveServerHeader nicht vorhanden, denn sie bringt keinen entscheidenden Sicherheitsvorteil. Die meisten Angriffe sind nicht betriebssystemspezifisch. Es gibt andere Möglichkeiten, die Identität des Servers festzustellen und Informationen über das Betriebssystem zu erhalten.
EnableLogging, PerProcessLogging und PerDayLogging: UrlScan ist kein Teil des IIS-Server-Kernels, sondern ein zusätzliches Werkzeug. Daher produziert es auch seine eigenen Protokolldateien. Mit diesen Funktionen können Sie verschiedene Aspekte im Zusammenhang mit diesen Protokolldateien festlegen.IIS 6.0 speichert alle sicherheitsbezogenen Aktivitäten in den W3SVC-Protokollen. Anfragen, die aus sicherheitsbezogenen Gründen oder wegen ausführbaren Codes zurückgewiesen werden, werden als 404.2-Fehler protokolliert. Anfragen zu statischen Dateien, die aufgrund eines unbekannten Typs abgelehnt werden, werden als 404.3- Fehler identifiziert.
AllowLateScanning: Mit dieser Funktion können Sie festlegen, ob UrlScan die URLs vor oder nach anderen Filtern überprüfen soll. Es gibt eine Reihe von Filtern, die URLs verändern. In diesem Fall ist es unter Umständen wünschenswert, URLs erst nach der Veränderung zu überprüfen. Ein Beispiel für diese Art von Filtern sind die Filter der FrontPage-Servererweiterungen.Die Funktion AllowLateScanning ist unter IIS 6.0 nicht erforderlich, da die Absicherungsmechanismen hier nicht von Benachrichtigungen durch Filter abhängen. IIS 6.0-Mechanismen basieren auf dem Code, dessen Ausführung für die vom Client angefragte URL nicht gestattet ist.
RejectResponseUrl: Diese Funktion arbeitet mit UseFastPathReject zusammen. Falls die Einstellung für UseFastPathReject auf 0 gesetzt ist, werden alle abgelehnten Anfragen auf die unter RejectResponseUrl angegebene URL weitergeleitet. Wenn diese URL nicht existiert, erhält der Client eine 404-Fehlermeldung – so, als hätte er tatsächlich eine nicht bestehende URL angefragt. Sie haben allerdings auch die Möglichkeit, die Meldung an den Client entsprechend Ihren Anforderungen anzupassen.IIS 6.0 speichert alle sicherheitsbezogenen Aktivitäten in den W3SVC-Protokollen. Anfragen, die IIS aus sicherheitsbezogenen Grünen oder wegen ausführbaren Codes zurückweist, werden als 404.2-Fehler protokolliert. Anfragen zu statischen Dateien, die aufgrund eines unbekannten MIME-Typs abgelehnt werden, werden als 404.3-Fehler identifiziert. Als Administrator können Sie die benutzerspezifisch konfigurierbaren Fehlermechanismen von IIS nutzen, um diese Antworten zu steuern.
UseFastPathReject: Die Absicherung von UrlScan hängt davon ab, dass in einem frühen Stadium des Verarbeitungsprozesses eine Benachrichtigung über einen Filter erfolgt. Daher kann auch nicht der normale 404-Fehler als Antwort zurückgesendet werden, wenn UrlScan die Anfrage aufgrund der Benachrichtigung ablehnt. Der Client wird wahrscheinlich eher eine kurze Fehlermeldung als die ausführliche benutzerdefinierte Meldung erhalten. Falls die Einstellung für UseFastPathReject auf 0 gesetzt ist, werden alle abgelehnten Anfragen auf die unter RejectResponseUrl angegebene URL weitergeleitet. 
AllowHighBitCharacters:Mithilfe dieser Funktion kann UrlScan Zeichen erkennen, bei denen es sich nicht um ASCII-Zeichen handelt.Der erlaubte Zeichenbereich wird von HTTP.SYS verwaltet und kann über den folgenden Registrierungsschlüssel geändert werden: HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\HTTP\Parameters\EnableNonUTF8.
MaxAllowedContentLength: Mit dieser Funktion kann UrlScan die Größe von Anfragen beschränken.IIS 6.0 ist von sich aus in der Lage, die Größe von Anfragen zu beschränken. Die Konfiguration erfolgt über die Metabase-Eigenschaften MaxRequestEntityAllowed und ASPMaxRequestEntityAllowed.
MaxUrl, MaxQueryString und MaxHeader: Mit diesen Funktionen kann UrlScan die Größe von URLs, Abfragestrings und bestimmten Headern beschränken.

Die IIS 6.0-Komponente HTTP.SYS ermöglicht das Beschränken von Anfragen. Die Konfiguration erfolgt über die Werte AllowRestrictedChars, MaxFieldLength, UrlSegmentMaxLength und UrlSegmentMaxCount.
Sie finden die Werte unter den Registrierungsschlüsseln:

  • HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\HTTP\Parameters\AllowRestrictedChars

  • HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\HTTP\Parameters\MaxFieldLength

  • HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\HTTP\Parameters\UrlSegmentMaxLength

  • HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\HTTP\Parameters\UrlSegmentMaxCount

Warnung: Ein Fehler bei der Bearbeitung der Registrierung könnte Ihr System schwer beschädigen. Bevor Sie Änderungen an der Registrierung vornehmen, sollten Sie eine Sicherung aller wichtigen Daten vornehmen.


UrlScan kann auch zusammen mit IIS 6.0 eingesetzt werden. Hierfür spricht, dass UrlScan einige Funktionen zur Absicherung von Webservern bietet, die mit IIS 6.0 nicht zur Verfügung stehen. UrlScan ist ein sehr flexibles Werkzeug und wird von einigen Kunden für Zwecke genutzt, die in diesem Artikel nicht beschrieben sind. Mehrere Organisationen haben UrlScan außerdem in die Verwaltungsprozesse ihrer IIS-Server aufgenommen. Aus diesen Gründen könnten Sie sich für eine gemeinsame Verwendung von UrlScan 2.5 und IIS 6.0 entscheiden.

>Weitere Informationen zu UrlScan 2.5 finden Sie im Microsoft Knowledge Base-Artikel 307608 - Verwenden von URLScan auf IIS.

Zum SeitenanfangZum Seitenanfang

UrlScan 2.5 installieren

Sie können UrlScan 2.5 auf Systemen mit IIS 4.0 oder höher installieren. Upgrades werden ebenfalls unterstützt.

So installieren Sie UrlScan 2.5:

  1. Laden Sie sich UrlScan 2.5 (engl.) herunter.

  2. Klicken Sie doppelt auf Setup.exe.

  3. Lesen Sie die Endbenutzervereinbarung, und klicken Sie auf Yes.

  4. Sobald das Setup beendet ist, wird die folgende Meldung angezeigt: "UrlScan has been successfully installed". Klicken Sie auf OK, um die Installation abzuschließen.

So deinstallieren Sie UrlScan:

  1. Klicken Sie in der Systemsteuerung auf Software.

  2. Wählen Sie UrlScan 2.5 aus, und klicken Sie auf die Schaltfläche Ändern/Entfernen.

  3. Sobald UrlScan 2.5 von Ihrem Server entfernt ist, wird die folgende Nachricht angezeigt: UrlScan has been successfully uninstalled. Klicken Sie auf OK, um den Deinstallationsprozess abzuschließen.

Informationen zum Installationsprogramm von UrlScan 2.5

Wenn UrlScan 2.5 installiert wird, führt das Installationsprogramm folgendes aus:

  • Er installiert die Dateien UrlScan.dll und UrlScan.ini im Ordner %windir%\system32\inetsrv\UrlScan. Wenn UrlScan bereits auf diesem Computer installiert ist, werden die Dateien aktualisiert.

  • Er fügt einen globalen Filter zu IIS hinzu.

Wenn Sie UrlScan auf einem Server mit IIS 6.0 installieren, werden einige zusätzliche Änderungen vorgenommen (diese sind erforderlich, damit UrlScan 2.5 mit dem neuen Prozessmodel von IIS 6.0 arbeiten kann). Hierbei handelt es sich um die folgenden Änderungen:

  • PerProcessLogging wird in der Datei UrlScan.ini auf 1 gesetzt. Dies stellt sicher, dass nicht zwei UrlScan-Prozesse zur gleichen Zeit in die Protokolldatei schreiben.

  • UrlScan wird in der Metabase für die Cache-Erkennung markiert. Dies stellt sicher, dass nicht zwei UrlScan-Prozesse zur gleichen Zeit in die Protokolldatei schreiben.

  • Ein neues Protokollverzeichnis wird als Unterordner unter \inetsrv\UrlScan erstellt. Dies stellt sicher, dass das UrlScan-Verzeichnis nicht mit den vielen von der Funktion PerProcessLogging produzierten Protokolldateien gefüllt wird.

Wenn Sie UrlScan 2.5 unter früheren Versionen von IIS installieren, werden Berechtigungen für die Dateien UrlScan.dll, UrlScan.ini und für die Protokolldateien eingerichtet. Wenn Sie UrlScan unter IIS 6.0 installieren, werden weitere zusätzliche Berechtigungen konfiguriert. Diese Berechtigungen ermöglichen es UrlScan 2.5, mit der Prozessisolation von IIS 6.0 zu arbeiten. Die bei der Installation von UrlScan 2.5 gesetzten Berechtigungen sind in Tabelle 2 aufgeführt.

Tabelle 2: Berechtigungen

Datei/VerzeichnisBerechtigungen
..\inetsrv\urlscan\urlscan.dllLesen und Ausführen (nur unter IIS 6.0): LOKALER DIENST, IIS_WPG und NETZWERKDIENST
Vollzugriff: Administratoren und SYSTEM
..\inetsrv\urlscan\urlscan.iniLesen (nur unter IIS 6.0): LOKALER DIENST, IIS_WPG und NETZWERKDIENST
Vollzugriff: Administratoren und SYSTEM
..\inetsrv\urlscan\logsesen und Schreiben (nur unter IIS 6.0): LOKALER DIENST, IIS_WPG und NETZWERKDIENST
Vollzugriff: Administratoren und SYSTEM


Wenn festgestellt wird, dass schon eine Version von UrlScan auf dem Computer vorhanden ist, wird ein Upgrade statt einer Installation durchgeführt. Bei einem Upgrade entsprechen die Berechtigungsänderungen denen, die bei einer Installation vorgenommen werden - es sei denn, Sie haben einen abweichenden Protokollordner konfiguriert. Wenn Sie die UrlScan- Protokolle an eine andere Position verschoben haben, werden die neuen Protokollverzeichnisse nicht erstellt.

Zum SeitenanfangZum Seitenanfang

Häufig gestellte Fragen

  • Was ist UrlScan?

  • Arbeitet UrlScan 2.5 mit IIS 6.0 zusammen?

  • Ich nutze schon Version 2.0 von UrlScan. Warum sollte ich das Update herunterladen?

  • Ich habe UrlScan für meine Website bereits passend konfiguriert. Überschreibt UrlScan 2.5 meine aktuellen Konfigurationseinstellungen?

  • Wenn UrlScan 2.5 mein System gegen Sicherheitsprobleme schützt, ist es dann trotzdem notwendig, die Patches zu installieren?

  • Ich bin nicht sicher, ob ich in einer meiner Anwendungen gestückelte Anfragen (Chunked-Transfer Encoding) verwendet. Was ist das?

Frage: Was ist UrlScan?

Antwort:UrlScan prüft alle auf dem Server eingehenden Anfragen und filtert sie nach den vom Administrator festgelegten Regeln. Da der Server dann nur noch gültige Anfragen ausführt, erhöht dies die Sicherheit des Systems. Die meisten gefährlichen Angriffe weisen ein gemeinsames Merkmal auf: Sie verwenden eine Anfrage, die auf irgendeine Art ungewöhnlich ist. Die Anfrage könnte zum Beispiel extrem lang sein, eine ungewöhnliche Aktion anfordern, mit einem alternativen Zeichensatz codiert sein oder Zeichenketten enthalten, die in legitimen Anfragen normalerweise nicht vorkommen. Indem es alle ungewöhnlichen Anfragen filtert, verhindert UrlScan, dass potenziell schädliche Anfragen den Server erreichen.

Frage: Arbeitet UrlScan 2.5 mit IIS 6.0 zusammen?

Antwort:Ja. UrlScan 2.5 ist die einzige Version, die von Microsoft für die Nutzung mit IIS 6.0 unterstützt wird.

Frage: Ich nutze schon Version 2.0 von UrlScan. Warum sollte ich das Update herunterladen?

Antwort:UrlScan 2.5 bietet die folgenden neuen Features:

  • Verzeichnisse für Protokolldateien ändern.

  • Lange URLs protokollieren.

  • Größe von Anfragen beschränken.

Frage: Ich habe UrlScan für meine Website bereits passend konfiguriert. Überschreibt UrlScan 2.5 meine aktuellen Konfigurationseinstellungen?

Antwirt:Nein. UrlScan 2.5 fügt der Konfigurationsdatei nur neue Einträge hinzu. Vorhandene Einträge werden nicht verändert.

Frage: Wenn UrlScan 2.5 mein System gegen Sicherheitsprobleme schützt, ist es dann trotzdem notwendig, die Patches zu installieren?

Antwort:Ja, dies ist auf jeden Fall notwendig. Patches stellen den letztendlichen Schutz gegen Sicherheitslöchern dar. Microsoft empfiehlt Ihnen dringend, zum Schutz Ihres Systems alle Sicherheitspatches so schnell wie möglich zu installieren.

Frage: Ich bin nicht sicher, ob ich in einer meiner Anwendungen gestückelte Anfragen (Chunked-Transfer Encoding) verwendet. Was ist das?

Antwort:Gestückelte Anfragen (Chunked-transfer Encoding) ist ein Feature von HTTP/1.1, bei dem die Anfragen in einzelnen Teilen mit Angabe ihrer jeweiligen Größe versendet werden können. HTTP 1.1 ermöglicht es, Clients POST-Anfragen mit Chunked-transfer Encoding zu verwenden. In den meisten Fällen werden solche Anfragen von IIS automatisch vor der Verarbeitung decodiert. Wenn die Größe einer Anfrage einen bestimmten Wert überschreitet (standardmäßig 48 KB), muss der ISAPI- oder CGI-Code, an den die Anfrage weitergeleitet wird, wissen, dass es sich um eine Chunked-transfer Encoding-Anfrage handelt - andernfalls kann er sie nicht korrekt verarbeiten. Wenn Sie Code auf einem Server ausführen, der POST-Anfragen verarbeitet, und sich nicht sicher sind, ob dieser Code Chunked-transfer Encoding unterstützt, dann können Sie mit UrlScan Anfragen mit einem "Transfer-Encoding"-Header verbieten. Weitere Informationen finden Sie in Kapitel 3.6.1 von RFC 2616 (engl.).

 

Zum SeitenanfangZum Seitenanfang

Microsoft führt eine Onlineumfrage durch, um Ihre Meinung zur -Website zu erfahren. Wenn Sie sich zur Teilnahme entscheiden, wird Ihnen die Onlineumfrage angezeigt, sobald Sie die -Website verlassen.

Möchten Sie teilnehmen?