httpd-users-de mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: seltsamer Redirect bei WebDAV
Date Mon, 02 Jan 2012 11:31:29 GMT
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 users-de-unsubscribe@httpd.apache.org
           sonstige Anfragen an users-de-help@httpd.apache.org
--------------------------------------------------------------------------


Mime
View raw message