Hi Guys,

We are deploying our application in a new environment/infrastructure, where
it would sit behind a load-balancer and the
application/apache-server/virtual-host setup has changed a little, and is
causing problems in redirect scenarios, for which I want some help.

So here is the problem.

The virtual host definition (in virtual_host.conf in apache) against each of
the website hosted is now configured to listen on a non-default port (e.g. 
8081, 8082, 8083 etc). With that wherever Wicket pages has some redirection
logic built into it, e.g. using RedirectResponseException or
setResponsePage(Page.class), or any other means which involves redirection
(301/302), it is now injecting the port in the url e.g.
http://mydomainname:8081/request/uri. I was of the understanding that Wicket
always uses relative urls, even for redirect, as also implied in this ticket
(https://issues.apache.org/jira/browse/WICKET-2728) but apparently that is
not the case. Let me add that none of these redirect scenarios where this
problem is happening, we are not constructing/providing the url to forward
to, and in fact are using the framework api(s) (as above) itself to redirect
to different pages within the same application.

Can please someone guide me there as to how to fix this issue. Similarly
given the SSL enforcement is now taking place at the load-balancer level
(and not at the apache layer), the absolute url which is constructed is also
using http:// instead of https://, given the traffic within the network is
over http. All these problems are coming into play due to the
usage/construction of absolute urls.

Please guide..using 1.4.18 version.

Thanks in advance,

Farhan.

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Wicket-generates-absolute-urls-for-redirects-301-Whats-the-way-out-tp4577479p4577479.html
Sent from the Users forum mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to