In welchem Falle sollte eine URI am Ende einen / haben und wann nicht?
Hintergrund meiner Frage:
mod_proxy hat beim eingeschaltem PreserveHost Probleme beim Rewrite des
Location-Headers das Protokoll korrekt zu setzen, wenn kein / am Ende der
URI ist.
> mod_proxy hat beim eingeschaltem PreserveHost Probleme beim Rewrite des
> Location-Headers das Protokoll korrekt zu setzen, wenn kein / am Ende
> der URI ist.
Das wäre ein schwerer Bug. Schreib einen Bug-Report.
Vorher würde ich aber nochmal checken, ob es nicht irgendeine sinnlose Default-Einstellung gibt, die bei Verzeichnissen explizit http erzwingt. (Solchen Schwachsinn soll es ja nicht nur bei WinXX geben. ;-)
> In welchem Falle sollte eine URI am Ende einen / haben und wann nicht?
Ich hätte jetzt gesagt: Wenn nicht eine Datei, sondern ein Verzeichnis
bezeichnet wird (und die URI nicht vollständig ist, sondern realiter
eine Default-Ressouce angezeigt wird).
On 2012-01-21 10:01, Thomas Hochstein <t...@inter.net> wrote:
> Chris Seidel schrieb:
>> In welchem Falle sollte eine URI am Ende einen / haben und wann nicht?
> Ich hätte jetzt gesagt: Wenn nicht eine Datei, sondern ein Verzeichnis
> bezeichnet wird (und die URI nicht vollständig ist, sondern realiter
> eine Default-Ressouce angezeigt wird).
Vielleicht oder vielleicht auch nicht. Wie der Server URLs interpretiert
hängt allein vom Server ab. Es kann sein, dass der Server auf ein
Filesystem zugreift und nach einem File namens "index.html" in dem
bezeichneten Directory sucht, aber es kann auch sein, dass der Pfad eine
eine Resource in einer Datenbank bezeichnet, oder ganz was anderes.
Mir fällt nur eine Ausnahme ein: http://foo.com und http://foo.com/ bezeichnen tatsächlich beide /per definitionem/ die gleiche Resource,
und die erste Form ist die kanonische (leider - ich finde die zweite
Form logischer).
hp
-- _ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | h...@hjp.at | __/ | http://www.hjp.at/ | -- Bill Code on a...@irtf.org
Peter J. Holzer wrote:
> Mir fällt nur eine Ausnahme ein: http://foo.com und http://foo.com/ > bezeichnen tatsächlich beide /per definitionem/ die gleiche Resource,
> und die erste Form ist die kanonische […]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Wo steht das geschrieben?
PointedEars
-- Nimm VerBrecherSCRIPT, denn das ist kein JavaScript-Objekt, wird also bei
keinem vernünftigen Browser geschweige denn auf einer vernünftigen Plattform
funktionieren, so daß Du auch [...] gleich mit VBSCRIPT arbeiten kannst und
dies auch tun solltest. -- Georg Maaß in dcljs
On 2012-01-22 02:39, Thomas 'PointedEars' Lahn <PointedE...@web.de> wrote:
> Peter J. Holzer wrote:
>> Mir fällt nur eine Ausnahme ein: http://foo.com und http://foo.com/ >> bezeichnen tatsächlich beide /per definitionem/ die gleiche Resource,
>> und die erste Form ist die kanonische […]
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Wo steht das geschrieben?
Gute Frage. Ich dachte, es wäre RFC 1738 gewesen, aber dort finde ich nur:
| If neither <path> nor <searchpart> is present, the "/"
| may also be omitted.
Der war es also nicht. Aber es müsste ein RFC aus dieser Zeit (Mitte der
90er-Jahre) gewesen sein.
In RFC 3986 hingegen steht:
| http://example.com | http://example.com/ | http://example.com:/ | http://example.com:80/ |
|
| In general, a URI that uses the generic syntax for authority with an
| empty path should be normalized to a path of "/". Likewise, an
| explicit ":port", for which the port is empty or the default for the
| scheme, is equivalent to one where the port and its ":" delimiter are
| elided and thus should be removed by scheme-based normalization. For
| example, the second URI above is the normal form for the "http"
| scheme.
Das widerspricht meiner Erinnerung also direkt und definiert das so, wie
es meiner Meinung nach sein sollte. Das freut mich, also werde ich in
Zukunft RFC 3986 zitieren und vergessen, jemals etwas anderes gelesen zu
haben.
hp
-- _ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | h...@hjp.at | __/ | http://www.hjp.at/ | -- Bill Code on a...@irtf.org
