URI mit oder ohne / am Ende

[Chris Seidel]

Hallo,

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.

z.B.

Proxy: foo.com
Backend: foo.de


https://foo.de/123 -> http://foo.com/123

https://foo.de/123/ -> https://foo.com/123/

Danke

[Marcel Müller]

Hallo,

On 20.01.2012 18:35, Chris Seidel wrote:
> In welchem Falle sollte eine URI am Ende einen / haben und wann nicht?

beides ist erlaubt. Der Server kann letztlich bei "http://server/pfad"
etwas komplett anderes ausliefern als bei "http://server/pfad/", es ist
ja ein anderer URI. Üblich ist allerdings bei "http://server/pfad" ein
Redirect auf "http://server/pfad/" zu liefern.

> 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.
>
> z.B.
>
> Proxy: foo.com
> Backend: foo.de
>
> https://foo.de/123 -> http://foo.com/123

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. ;-)

> https://foo.de/123/ -> https://foo.com/123/

Marcel

[Thomas Hochstein]

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).

> https://foo.de/123 -> http://foo.com/123
>
> https://foo.de/123/ -> https://foo.com/123/

Gemeint wohl in beiden Fällen:
https://foo.com/123/index.html (o.ä.)

Grüße,
-thh

[Peter J. Holzer]

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.

Wie Marcel bereits richtig geschrieben hat, sind http://foo.com/123 und
http://foo.com/123/ verschiedene URLs, die verschiedenenen Content
bezeichnen können, und beide sind auch wieder verschieden von
http://foo.com/123/index.html.

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 as...@irtf.org

[Thomas 'PointedEars' Lahn]

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

[Peter J. Holzer]

On 2012-01-22 02:39, Thomas 'PointedEars' Lahn <Point...@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.