Actually - I spoke too soon :) When I use SC_SEE_OTHER inside an AJAX invoked form submit method it works fine if the URL is for the same hostname but when it points to a different hostname (external link) the browser refuses to redirect, giving a CORS error.
I could configure CORS on the external server but this is a redirect so I am wondering why is CORS an issue? Maybe the browsers treats all XMLHttpRequestS as resource accesses to display in the current page even if they are not actually requesting a resource to be displayed in the current page but invoking redirect to a completely new page? The redirect 302 doesn't have this problem but then I'm back to the undesirable premature decoding of the query parameters. It seems like the browser understands that 302 is a proper redirect (not a resource fetch for the current page) and so does not raise a CORS error. That got me thinking that may I could use SC_TEMPORARY_REDIRECT instead but that results in a: java.lang.IllegalStateException: Status must be either 301, 302 or 303, but was: 307 > -----Original Message----- > From: Chris Colman [mailto:chr...@stepaheadsoftware.com] > Sent: Wednesday, 27 February 2019 9:06 PM > To: users@wicket.apache.org > Subject: RE: Undesirable decoding of URL encoded external URL using > RedirectToUrlException > > That works brilliantly! > > Thanks Martin > > > -----Original Message----- > > From: Martin Grigorov [mailto:mgrigo...@apache.org] > > Sent: Tuesday, 26 February 2019 10:46 PM > > To: users@wicket.apache.org > > Subject: Re: Undesirable decoding of URL encoded external URL using > > RedirectToUrlException > > > > Hi, > > > > It seems you use RedirectToUrlException(String) constructor which > > internally uses statusCode=HttpServletResponse.SC_MOVED_TEMPORARILY. > > If you use RedirectToUrlException(yourUrl, > > HttpServletResponse.SC_SEE_OTHER) then Wicket will not do its extra > logic > > in > > > org.apache.wicket.protocol.http.servlet.ServletWebResponse#encodeRedirec > tU > > RL() > > and all should be fine. > > > > On Mon, Feb 25, 2019 at 8:13 PM Chris Colman > > <chr...@stepaheadsoftware.com> > > wrote: > > > > > I am using: > > > > > > > > > > > > throw new RedirectUrlException(externalUrl); > > > > > > > > > > > > to redirect to an external URL (i.e. > > > https://hostname/path?param1=value1¶m2=value2 etc.,) > > > > > > > > > > > > In constructing the URL I have used java.net.URLEncoder.encode() to > > > individual encode the values in each of the query parameters. > > > > > > > > > > > > The browser shows the redirected URL with the query parameters being > > > 'decoded' not encoded. > > > > > > > > > > > > I stepped through in the debugger and saw that Wicket's > > > org.apache.wicket.util.encoding.UrlDecoder is being used to decode > the > > > URL while processing the redirect. > > > > > > > > > > > > > > > > > > I worked around problem by using the native Servlet API redirect: > > > > > > > > > > > > HttpServletResponse response = > > > > (HttpServletResponse)getRequestCycle().getResponse().getContainerRespons > > > e(); > > > > > > try > > > > > > { > > > > > > response.sendRedirect(url); > > > > > > } > > > > > > catch(IOException ioe) > > > > > > { > > > > > > logger.error("Error while attempting to > redirect > > > to: " + url); > > > > > > } > > > > > > > > > > > > However, is there a 'Wicket' way of redirecting to an external URL > > > without causing the undesired decoding? > > > > > > > > > > > > > > > > > > Note: Using Wicket 6.x > > > > > > > > > > > > Regards, > > > > > > Chris > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org