We've recently experienced some problems with mounted URLs where the wicket internals incorrectly handle the mounting, specifically this problem occurs due to lazy decoding and encoding of mounted URLs when redirecting.
Example: We have two pages called ArticlePage & ArticlePageProxy, which either takes an article id parameter from the URL or decodes the requested mount url and gets the parameters from a database. We've found this to be a very handy way of dealing with the need for clean URLs and makes the system nice and extensible. The customer can for instance write an article about contact details and mount that article under /contact and when that will appear as a fully functional page displaying the article. Problems occur when users start to use multi-tab browsing, what happens when a user opens a new tab and points it at say /contact?; Wicket will detect that this is a new tab and open a new pagemap, the page will begin to render but contains a redirect to the new URL with the pagemap parameter included in URL. This is where the error occurs, the redirect URL has been created by decoding the requesting page (ArticlePage for instance) and then re-encoding it if it is mounted. Now say for example that our customer also mounts /alpha-code, and /alpha-code is mounted before /contact in wicket. Now whenever a user opens a new tab to /contact, he is redirected to /alpha-code with the pagemap parameter. Now this might not seem like a problem to wicket because they are both the same class, but if a page is mounted on several URLs it is likely that the requesting URL is somehow important to the page and should be kept intact. IRequestTargetUrlCodingStrategy getMountEncoder(IRequestTarget requestTarget) line 1057 of WebRequestCodingStrategy (in v.1.4.9) is never supplied with the initial URL for the request and thus can't make an intelligent decision. I have been unable to find exactly where in the source code the redirect with the new pagemap occurs however at that point I'd presume the Request is still intact and the requesting URL could simply be plucked out from there. I'll try to put up a Jira and example over the weekend. If anyone know where the redirect occurs and if its possible to overload it with a more intelligent option, that would be much appreciated. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Incorrect-handling-of-mounted-URLs-internally-leads-to-problems-tp2543596p2543596.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
