Hi, To avoid such problems in the future I suggest you to setup Apache HTTPD in your development setup so it looks like your production one.
On Fri, Oct 19, 2012 at 7:28 AM, Dirk Forchel <dirk.forc...@exedio.com> wrote: > Hallo Sven, > I doubt it. I don't wanna blame the HttpsMapper as the mapping is done in > the usual way as RootRequestMapper: > > Application#init() > > > There is no magic and there were no changes at all. Since we upgraded our > application from Wicket 1.5.5 to Wicket 1.5.8 and/or Wicket 6 (NOTE: we have > the same application on two branches with different Wicket verions) we have > this problem with wrong rendered secure Links. > As mentioned above, I've adapted your solution to pre-save the protocol and > the port and this solution works on my local developer machine running with > Tomcat on http://localhost:8080/ and https://localhost:8443/ respectively. > But if we deploy this application on another machine with Tomcat and an > Apache WebServer (connected to Tomcat via AJP connector) in front, we got > these wrong rendered links. The request Urls to the Apache WebServer look > like http://mydomain.com/ and https://mydomain.com/. Note: there are no > ports in the requests, needless to say that Tomcat listens on port 80 and > 443. I guess you made mistake here. HTTPD is listening at ports 80/443 and Tomcat at 8080/8443, right ? > > I could figure out, that on the remote machine, the pre-served port value is > 'null' and not '443' as it should be. Why?! On my local machine the > pre-served port is '8443'. If the pre-served port value is null, the method > resolvePort(url) returns '80' as resolved port value, which is WRONG!!! AJP has its own connector in Tomcat, by default listening on port 8009. Most probably this is the reason why #getServerPort() returns the wrong value. You can create a ticket with detailed description how to setup the same environment as yours and I can take a look. Just provide your Tomcat server.xml and AJP related conf for HTTPD. And a Wicket quickstart, of course. > > > > The returned port value in this case is the second fallback ( > request.getClientUrl().getPort() ). > Do you have any idea why 'null' is pre-served and not '443'? > > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/UrlRenderer-renders-wrong-HTTPS-links-tp4653059p4653080.html > Sent from the Users forum mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
