IE ignores 303 redirect in POST -> redirect -> GET scenario

Question

I have an OAuth2 enabled site that experiencing issues related to how IE is handling the 303 response. In the flow, 3 redirects occur.

### Chrome/Firefox
POST idp.com/login           (res 302 -> idp.com/authenticate)
GET  idp.com/authenticate    (res 302 -> app.com/oauth2/callback)
GET  app.com/oauth2/callback (res 303 -> app.com/home)
GET  app.com/home

### IE
POST idp.com/login           (res 302 -> idp.com/authenticate)
POST idp.com/authenticate    (res 302 -> app.com/oauth2/callback)
POST app.com/oauth2/callback (res 303 -> app.com/home)
POST app.com/home

IE seems to be maintaining the original request method for some reason. I tried to at least break from the original POST response on my server (app.com) by returning a 303 but that did not solve the issue either. This is unexpected since RFC 2068 states that for a 303 - See Other response, the following should be honored

The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource.

I even tried a 307 response with no success. Does anyone have any ideas on what's happening here?

Pepper

seeing a similar behavior when doing OAuth to LinkedIn - IE is POSTing the callback not GETing it. – Illation

related question - #9912700 but still no answer – Illation

Answer 1

Having encountered a similar problem with LinkedIn OAuth and my application, I solved this in a particularly inelegant manner. I allowed the POST method for my callback address and then internally in my servlet implementation treated it the same as if it were a GET call.

    @RequestMapping(value = ApiValues.LINKEDIN_CALLBACK, method = RequestMethod.POST)
public void doPost(HttpServletRequest request, HttpServletResponse response,
        @RequestParam(value = "oauth_token", required = false) String tokenString,
        @RequestParam(value = "oauth_verifier", required = false) String verifierString) throws ServletException, IOException {

    handleCallBack(request, response, tokenString, verifierString);
}


@RequestMapping(value = ApiValues.LINKEDIN_CALLBACK, method = RequestMethod.GET)
public void doGet(HttpServletRequest request, HttpServletResponse response,
        @RequestParam(value = "oauth_token", required = false) String tokenString,
        @RequestParam(value = "oauth_verifier", required = false) String verifierString) throws ServletException, IOException {

    handleCallBack(request, response, tokenString, verifierString);
}

Noted it only seems that IE (and older versions of IE) are providing this problem, Chrome, Firefox and Safari all seem to redirect to GET as per spec.

Illation

Answer 2

Don't believe the IE debugger tools if you're using it. The network panel will combine previous request (POST) with current request (GET) for 303 & 302. Thus, you will see a POST in network panel, but the truth is only GET request. Try to use Charles, or other HTTP monitor tool to check the requests.

Seismograph