Hi Michael,
On 02.01.2012 11:35, Reindl Harald wrote:
Am 02.01.2012 11:13, schrieb Michael Renner:
Klar, da fehlte etwas. Jetzt findet die passende Umsetzung von /renner auf
renner/ statt. Doch leider geht dabei das https verloren. Aus den Headern
vom Aufruf:
Klar, siehe unten
Als ServerName ist in der httpd.conf
ServerName https://webdav.domain.tld:443
gesetzt. Hilft nix :-(
Weil das Unsinn ist und kein Servername
Na ja, laut Doku und Code geht das bei 2.2.21 schon, auch wenn ich das
bis gerade eben auch nicht wusste. Und interessanterweise setzt es auch
intern genau das Scheme-Feld am (virtuellen) Server, welches beim
Redirect-Ausführen zum absolut machen der URL verwendet wird.
Michael: Du solltest aber checken, ob Du diesen ServerName auch in dem
VHost gesetzt hast, der den Request abbekommt.
Außerdem bin ich nicht sicher, ob Du Dir durch diesen Hack unangenehme
Seiteneffekte reinholst.
Der Trailing-Slash-Redirect, den Du siehst, kommt vom mod_dir im RP,
d.h. schon bevor mod_proxy zuschlägt. Wenn es nicht gelingt den
Trailing-Slash-Redirect zu fixen, etwa so wie Du das schon versucht
hast, kannst Du ihn auch alternativ mit "DirectorySlash Off" (evtl. im
VHost) auf dem RP abstellen. Dann geht der Request zunächst zum
WebDAV-Apache durch, und dort passiert ggf. der gleiche
Trailing-Slash-redirect (je nach Konfig).
Auf dem Web zurück kommt dann zwar ProxyPassReverse zum tragen, aber
erneut muss dort aus einer lokalen URI eine volle URL gemacht werden.
Ohne Trick kommt da eben wieder eine http-URL raus, weil der RP nix von
https weiß. An sich sollte aber Dein ServerName-Trick klappen. Es kann
halt nur sein, dass er andere negative Seiteneffekte hat.
Die Crux ist, dass der Apache von SSL nichts weiss, da die SSL-Terminierung
schon
vorher in einem Stück Blech stattfindet, nicht am Apache selbst.
Tja und an dieser kranken Config liegt das Problem
Der Apache soll Proxy spielen und weiss selber nicht dass er https
ist - Was soll er dann machen wenn davor schon was Proxy spielt
du eine nicht existente URL eingibst, er so freundlich ist und
einen Redirect macht der nun mal RFC-Konform FQ stattzufinden hat
Das muss das Blech davor ausbügeln weil es die einzige Instanz
ist die weiss dass sei selber Proxy spielt, der Apache danach kann
dafür nichts
Stimmt, besser wäre der SSL-Endpunkt korrigiert diese Probleme.
Vermutlich leichter zu machen, besser zu verstehen und weniger
fehleranfällig.
Gruß
Rainer
--------------------------------------------------------------------------
Apache HTTP Server Mailing List "users-de"
unsubscribe-Anfragen an [email protected]
sonstige Anfragen an [email protected]
--------------------------------------------------------------------------
