Unterstützbarkeit von Umschreibungen und Umleitungen in SharePoint 2016, 2013, 2010 und 2007 – Microsoft Support

Unterstützbarkeit von Umschreibungen und Umleitungen in SharePoint 2016, 2013, 2010 und 2007

Zusammenfassung

In diesem Artikel wird erläutert, wie sich die Unterstützbarkeit auswirkt, wenn Sie URL-Umschreibungs- und -Umleitungsszenarien in Microsoft SharePoint Server mithilfe eines beliebigen URL-Bearbeitungstools konfigurieren, z. B. Internet Information Services (IIS) URL Rewrite.

Einige dieser Tools funktionieren möglicherweise wie erwartet, wenn Sie sie zum Konfigurieren einer URL-Umschreibung oder -Umleitung verwenden, die sich auf SharePoint bezieht. Wenn Sie jedoch die Unterstützungsfähigkeit für ein URL-Bearbeitungstool bewerten, das Sie zusammen mit SharePoint verwenden, sollten Sie berücksichtigen, dass Microsoft nicht alle möglichen Implementierungsszenarien gründlich getestet hat, die solche Tools verwenden.

Wichtig: Microsoft kann diese Tools nicht unterstützen oder Unterstützung für ihre Implementierung bereitstellen, wenn sie in Verbindung mit SharePoint verwendet werden.

Mehr Informationen

Die folgenden Informationen werden bereitgestellt, um zu zeigen, wie SharePoint im Allgemeinen funktioniert, wenn Sie URL-Umschreibung und -Umleitung verwenden.

Gemeinsame URL-Komponenten

Planen	Gastgeber	Weg	Abfragezeichenfolge
HTTP	www.contoso.com	/apps/default.aspx	?user=admin

Es gibt zwei Haupttypen von URL-Änderungen: Rewrite und Redirect .

Das Umschreiben ändert die eingehende URL, die ausgehende URL oder beides.

Die Umleitung verwendet HTTP-Statuscodes wie 301 oder 302, um den Client an einen anderen Ort umzuleiten. Dies beinhaltet einen zusätzlichen Client-Roundtrip.

Microsoft unterstützt keine Implementierungen von URL-Änderungen in Microsoft SharePoint Server 2016, Microsoft SharePoint Server 2013, Microsoft SharePoint Server 2010 oder Microsoft Office SharePoint Server 2007.

Beispielszenarien

Hinweis: Alle Szenarien in diesem Abschnitt verwenden den Application Request Routing (ARR)-Server als Proxy und verwenden URL Rewrite, um die URL zu ändern.

• ASYMMETRISCHE REWRITE-URL

  • Der Client stellt eine Anforderung an http://www.contoso.com/sites/site1

  • IIS mit ARR empfängt die Anforderung an http://www.contoso.com/sites/site1

  • ARR verwendet URL Rewrite, um die URL in http://www.contoso.com/site1 zu ändern

  • Die aktualisierte URL wird dann an die SharePoint-Webanwendung gesendet.

Dieses Szenario wird NICHT UNTERSTÜTZT .

• SYMMETRISCHE REWRITE-URL

  • Der Client stellt eine Anforderung an http://www.contoso.com/sites/site1.

  • IIS mit ARR empfängt die Anforderung an http://www.contoso.com/sites/site1.

  • ARR verwendet URL Rewrite, um die URL in http://www.fabrikam.com/sites/site1 zu ändern, und sendet dann die neue URL an den Server

  • SharePoint empfängt die neue URL und verarbeitet sie als http://www.fabrikam.com/sites/site1

Dieses Szenario wird UNTERSTÜTZT .

• HTTP-UMLEITUNG

  • Der Client stellt eine Anforderung an http://www.contoso.com/sites/site1.

  • IIS mit ARR empfängt die Anforderung an http://www.contoso.com/sites/site1.

  • ARR verwendet URL Rewrite, um eine Umleitung zu http://www.fabrikam.com/sites/site1 zu erstellen, und gibt dann die HTTP-Umleitung (z. B. 301 oder 302) an den Client zurück

  • Der Client empfängt die Umleitung und stellt dann eine neue Anforderung unter Verwendung der neuen URL: http://www.fabrikam.com/sites/site1.

  • SharePoint empfängt die Anforderung und verarbeitet sie wie gewohnt.

Dieses Szenario wird UNTERSTÜTZT .

Weitere Informationen finden Sie im Abschnitt „Reverse Proxy Publishing" im folgenden TechNet-Thema:

Planen einer alternativen Zugriffszuordnung (Office SharePoint Server)

Obwohl das Thema Office SharePoint Server 2007 erwähnt, gilt es auch für SharePoint 2016, SharePoint 2013 und SharePoint 2010.