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 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!!! 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
