Hi, I recently deployed XWiki Enterprise behind an Apache HTTP server acting as a reverse proxy. This was done in order to map the XWiki web interface into our intranet namespace and to perform SSL termination. To get this working, I had to resort to a few hacks and workarounds due to the fact that not all parts of XWIki Enterprise seem to be friendly towards reverse proxies. A workable solution was eventually achieved through config file changes and the addition of some Apache URL rewrite rules (e.g. redirect all requests for "http://foo.com/xwiki/bar" to "https://foo.com/xwiki/bar"). Today, I had to deploy another XWiki instance behind an Apache HTTP server, again for reasons of namespace consolidation and SSL termination. However, this time I do not have as much freedom as I had on the previous server and are finding myself stuck at this point. Examples of specific issues are that URLs of skin resources are served using the HTTP (i.e. insecure) protocol and some redirects are generated for the local address instead of the proxied address (e.g. login page from unauthorised and default post login redirect page). I'm not looking for particular solutions to these issues as much as trying to establish how likely I am to get this right and whether I'm trying to fit a square peg into a round hole. Specific questions as follows: 1. Did anyone manage to successfully deploy XWiki behind an HTTP reverse proxy without resorting to hacks and workarounds ? If so, please share some information about the magic configuration. Does the problem, perhaps, lie with Apache's reverse proxy module or its interaction with XWiki ? 2. Is my expectation to have XWiki working behind an HTTP reverse proxy misplaced ? If not, and XWiki does intend to support this, are the issues I describe above well known or should I report them somewhere ? Also, what can I do to help and contribute to such an effort ? 3. Are these issues due to the platform or the layers above it (e.g. skins and apps) ? Does the platform provide a "right way" that the layers above it can use to generate URLs that would always work correctly through a reverse proxy ? BTW, thanks for a great product! Regards, Gerhard -- Gerhard Esterhuizen Director Yila Consulting (Pty) Ltd PO Box 50461, Waterfront 8002, South Africa Phone: +27 82 370 9737 Fax: 086 549 5635 gerhard(a)yilaconsulting.com align. architect. execute.