GET request for redirect initiated by browser but not successful

Question

While trying to redirect user to a URL, it works with GET requests but not with postback requests.

Through firebug's Network window, I can see the redirect response received by browser after the postback request (that should cause redirect) completes. The browser seemingly initiates a GET request for the redirect URL but doesn't actually successfully redirect. It remains there on the same page.

 I use JSF server side. The initiated GET request is not received at all by the server. However initiated by the browser on server's demand. I guess problem is somewhere client side only 

Can anyone please explain how to make redirect work successfully ? Let me know incase I should provide any more information.

Edit:

Request header for redirect:

GET /Px10Application/welcome.xhtml HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:20.0) Gecko/20100101 Firefox/20.0
Accept: application/xml, text/xml, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://localhost:8080/Px10Application/channelPages.xhtml?channelId=-3412&type=Group
X-Requested-With: XMLHttpRequest
Faces-Request: partial/ajax
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Cookie: hb8=wq::db6a8873-f1dc-4dcc-a784-4514ee9ef83b; JSESSIONID=d40337b14ad665f4ec02f102bb41; oam.Flash.RENDERMAP.TOKEN=-1258fu7hp9
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

Response header for redirect:

HTTP/1.1 200 OK
X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1 Java/Sun Microsystems Inc./1.6)
Server: GlassFish Server Open Source Edition 3.1
Set-Cookie: oam.Flash.RENDERMAP.TOKEN=-1258fu7hp8; Path=/Px10Application
Pragma: no-cache
Cache-Control: no-cache
Expires: -1
Content-Type: text/xml;charset=UTF-8
Content-Length: 262
Date: Wed, 22 May 2013 17:18:56 GMT

Bulwark

Can you tell us something about your server-side? – Bamberg

@ShuklaSannidhya: I use JSF server side. The initiated GET request is not received at all by the server. However initiated by the browser on server's demand. I guess problem is somewhere client side only – Bulwark

@user01 - That information should be in the question body, not in a comment. – Yablon

What happens if you directly visit the 'redirect' via that same browser? – Barner

How are you redirecting? Can you post your code that you are using for redirection? – Bamberg

I redirect from within a filter class implemented for JSF using this code: response.sendRedirect(req.getContextPath() + "/welcome.xhtml"); – Bulwark

@user01 - and what does the actual HTTP redirect look like? Can you post it? – Barner

@m.edmondson: Added some info retrieved from firebug Net window to the question body. Is this what you asked for? – Bulwark

Answer 1

X-Requested-With: XMLHttpRequest
Faces-Request: partial/ajax

You're thus attempting to send a redirect on a JSF ajax request using "plain vanilla" Servlet API's HttpServletResponse#sendRedirect(). This is not right. The XMLHttpRequest does not treat a 302 response as a new window.location, but just as a new ajax request. However as you're returning a complete plain vanilla HTML page as ajax response instead of a predefined XML document with instructions which HTML parts to update, the JSF ajax engine has no clues what to do with the response of the redirected ajax request. You end up with a JS error (didn't you see it in the JS console?) and no form of visual feedback if you don't have the jsf.ajax.onError() handler configured.

In order to instruct the JSF ajax engine to change the window.location, you need to return a special XML response. If you have used ExternalContext#redirect() instead, then it would have taken place fully transparently.

externalContext.redirect(redirectURL);

However, if you're not inside JSF context, e.g. in a servlet filter or so, and thus don't have the FacesContext at hands, then you should be manually creating and returning the special XML response.

if ("partial/ajax".equals(request.getHeader("Faces-Request"))) {
    response.setContentType("text/xml");
    response.getWriter()
        .append("<?xml version=\"1.0\" encoding=\"UTF-8\"?>")
        .printf("<partial-response><redirect url=\"%s\"></redirect></partial-response>", redirectURL);
} else {
    response.sendRedirect(redirectURL);
}

If you happen to use JSF utility library OmniFaces, then you can also use Servlets#facesRedirect() for the job:

Servlets.facesRedirect(request, response, redirectURL);

See also:

• Authorization redirect on session expiration does not work on submitting a JSF form, page stays the same
• JSF Filter not redirecting After Initial Redirect

Kamasutra

I am curious, is there a reason you used append then printf, instead of just printf? I never used append earlier, and the API docs say it "Appends the specified character sequence to this writer." I guess when you use some of the print methods it automatically writes the parts appended earlier, right? So you used append just for convenience, or still there is another reason? – Collimator

@informatik01: It was just to break down long lines to fit in 120 char width. I'm not a fan of strings which continue to next line by +. You're of course to choose whatever way you want to achieve the same result. – Kamasutra