Apache-rewrite-Regel führenden Schrägstrich

Führenden Schrägstrich ersten argument: ignoriert?

Was die Unterschiede in der syntax zwischen

RewriteRule help help.php?q=noslash [L]     #1
RewriteRule /help help.php?q=withslash [L]  #2

Wenn ich auf http://localhost/help, es geht auf #1, wenn ich auf http://localhost//help es geht immer noch um #1.

Bin ich zu Recht sagen die führenden slash im ersten argument RewriteRule ist im wesentlichen ignoriert?

Führenden Schrägstrich zweite argument: Fehler?

Auch, warum nicht diese rewrite-Regel funktioniert?

RewriteRule help /help.php [L]     #1

Setzen einen führenden Schrägstrich vor dem zweiten arg-tatsächlich schafft ein 500 Fehler für den server. Warum?

Ich sollte anmerken, ich bin mit einem .htaccess-Datei zu schreiben, diese Regeln in

  • Was passiert, wenn Sie ändern Sie die Reihenfolge der beiden rewriterules? Wenn die ersten Spiele (und es tut), wird die zweite nicht ausgeführt.
  • irgendein besonderer Grund, versucht die Doppel-slashes in url?
  • Ah ja, du hast Recht. @yoda ich war einfach zu versuchen, um die zweite Regel zu gelten
InformationsquelleAutor bobobobo | 2010-12-22
  1. 13

    Seltsam genug, 

    RewriteRule   ^/help    help.php?q=2              [L]

    Die obige Regel nicht und nie entspricht.

    Diese Regel:

    RewriteRule   ^help      help.php?q=1             [L]

    Entspricht http://localhost/help, http://localhost//help und http://localhost///help

    Scheint es RewriteRule nie sieht führende Schrägstriche des Weges, und als TheCoolah sagte Sie sind zusammengebrochen (0.. wenn mit einem .htaccess-Datei sowieso), egal wie viele es sind.

    Für den zweiten Teil der Frage,

    RewriteRule   ^help    /help.php

    Ich bin immer die Antwort von Definitive Guide to Apache Mod_rewrite

    ... eine rewrite-Ziel, das beginnt nicht mit http://oder ein anderes Protokoll
    Kennung wird davon ausgegangen, dass ein file-system-Pfad. Datei-Pfade beginnen nicht mit einem slash interpretiert werden als relativ zum Verzeichnis, in dem die Umschreibung stattfindet.

    So /help.php sieht in der root des Systems nach einer Datei namens help.php, die sich auf meinem system nicht finden kann.

    Machen /help.php erscheinen als relative URL (relativ zur Wurzel der Website) können Sie mit dem [PT] - Richtlinie:

    RewriteRule   ^/help    /help.php    [PT]

    Leitet http://localhost/help zu http://localhost/help.php.

    • Es sieht aus wie der führende slash hat in der Tat passen, wenn Sie die Regel in der vhost config, aber nicht im Verzeichnis-Kontext.
    • Interessanterweise RedirectMatch Bedürfnisse der führende slash im pattern
    InformationsquelleAutor bobobobo
  2. 4

    Bezug auf doppelte Schrägstriche: die Meisten Web-Server still Zusammenbruch mehrere Schrägstriche in einem einzigen Schrägstrich früh in die request-Verarbeitung-pipeline. Dies gilt für mindestens Apache, Tomcat und Jetty. Die meisten Unix-basierten Datei-Systeme funktionieren auf die gleiche Weise. Wenn Sie wirklich wollen, um dies zu überprüfen, müssen Sie etwas tun, wie:

    RewriteCond %{REQUEST_URI} ^(.*)//(.*)$
    InformationsquelleAutor TheCoolah
  3. 1

    help entspricht "help" überall im Weg.

    /help passt nichts, da die rewriterule Richtlinie lässt die führende slash für passende Zwecke (D. H., müssen Sie ^, nicht / oder ^/, verweisen auf das aktuelle Verzeichnis).

    (Das kann sehr verwirrend sein, wenn Sie verwendet haben %{REQUEST_URI} im rewritecond weil %{REQUEST_URI} hat beginnen mit einem nachgestellten Schrägstrich. Beim Abgleich gegen %{REQUEST_URI}, ^ und ^/ gleichwertig sind und einen Verzeichnis-Namen werden immer mit einem vorangestellten Schrägstrich unabhängig davon, ob oder nicht es ist in der top-level-Verzeichnis.)

    Server die Fehler verursacht wird, durch eine unendliche Schleife. "Hilfe" wird "/help.php" das ist dann abgestimmt durch die gleiche Richtlinie, die den umschreiben. So, nach dem ersten match "/help.php" wird "/help.php" unendlich was in einer URL, die nicht aufgelöst werden können.

    Ich glaube, solche Schlaufen befestigt werden kann, mit der end flag (d.h., [end]), aber das flag benötigt Apache 2.3.9+ in der Erwägung, dass Apache 2.2 scheint häufiger zu sein in Bereitstellung. Es würde wohl besser sein, nur die Korrektur der reguläre Ausdruck sowieso; ^help$ zu sein scheint, ist die bessere Wahl hier.

    InformationsquelleAutor Patrick Dark
  4. 0

    Den Weg RewriteRule funktioniert, ist, dass, wenn auf den angegebenen regulären Ausdruck übereinstimmt, die Teil der Pfad-Teil der URL (der Teil hinter dem host und-port, aber vor dem query-string), dann den gesamten Pfad-Teil wird komplett ersetzt mit der angegebenen substitution. Dies erklärt das Verhalten, die Sie sehen in dem ersten Teil Ihrer Frage.

    Ich bin mir nicht sicher, was könnte die Ursache der 500-Fehler auf den zweiten Teil; vielleicht ist das kollabieren von doppelten Schrägstriche nicht geschehen, nach der rewrite-engine ausgeführt und erzeugt dann ein server-Fehler.

    • Beachten Sie auch, dass, es sei denn, Sie geben eine Besondere continue-flag (ich kann mich nicht erinnern), weitere rewrite-Regeln werden nicht angewendet, nachdem es eine übereinstimmung findet; und das matching geschieht, vom ersten bis zum letzten unter den angegebenen.
    InformationsquelleAutor
  5. -1

    Der Grund für den 500-Fehler ist ein Infinitiv-Loop:

    • die Hilfe wird neu geschrieben /Hilfe
    • /Hilfe bekommt abgestreift zu helfen
    • die Hilfe wird neu geschrieben /Hilfe
      etc. bis die MaxRewrites limit erreicht ist -> 500

    In der Erwägung, dass, wenn die Regel schreibt helfen zu helfen, Apache ist smart genug, um abzubrechen umschreiben an diesem Punkt.

    • Nein, die aufgrund der führenden Schrägstrich in das Ziel der re-schreiben, macht die dest interpretted als absoluter Pfad zu einer Datei auf der Festplatte, siehe meine Antwort
    InformationsquelleAutor wmbr
Schreibe einen Kommentar