|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #58615 google api status code 302 not supported
Submitted: 2009-04-04 04:06 UTC Modified: 2009-04-08 23:24 UTC
From: tjerk dot meesters at gmail dot com Assigned:
Status: Closed Package: oauth (PECL)
PHP Version: 5.2.8 OS: Gentoo Linux
Private report: No CVE-ID: None
 [2009-04-04 04:06 UTC] tjerk dot meesters at gmail dot com
Currently, the make_req function only accepts status code 
200 from the server.

Google API servers return this header to insert a session id 
inside the URL for optimization purposes.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-04-04 04:25 UTC] tjerk dot meesters at gmail dot com
Hmm, just enabling FOLLOWLOCATION inside curl doesn't do it 
for Google API though.

As it follows the new URL, the response turns into 401 
(Unknown authorization header) .. perhaps it doesn't expect 
any Authorization from that point onwards =S
 [2009-04-04 04:55 UTC] tjerk dot meesters at gmail dot com
Sorry for the stream of messages; after more investigation I 
found that the headers had to be resigned (duh!)

This means that redirection has to be handled outside of 
curl (i.e. can't just use FOLLOWLOCATION) but still inside 
make_req probably.

Alternatively, the URL of the redirection could be placed 
inside the getLastResponseInfo() output; though personally, 
it would be more preferable to handle this automatically.
 [2009-04-04 12:35 UTC]
This is tricky and I'm not sure right now how to deal with it...if at all. It is standard to forward all headers in the case of redirects though it might not be the case for OAuth interactions. That being said, I couldn't find anything in the official or "editor's cut" edition of the specification ( and, respectively) relating to this.

What about providers who expect the Authorization header to be forwarded along? I've asked Eran (OAuth's specification author) for clarification and am awaiting his response.

I did notice CURL_FOLLOWLOCATION wasn't set, so I've updated the code to set this along with a redirect limit. Can you cvs update and try HEAD? 

It might also be helpful if you can comment on the specific API where this is occuring. E-mail me directly if you don't feel comfortable posting the detailed information on the bug.
 [2009-04-04 21:49 UTC] tjerk dot meesters at gmail dot com
From my earlier research, I found out that it's not a question of whether to forward the Authorization headers; it's mandatory.

However, each request requires a proper nonce, so when following a link the request has to be resigned.

More information can be found on:

The following code works for me; I've changed the error condition inside the make_req to '>= 400' instead of '!= 200'




$oauth = new OAuth(

try {
  $req_token = $oauth->getRequestToken(''.SCOPE);
  echo ''.http_build_query(array(
    'oauth_callback' => '',
    'oauth_token' => $req_token['oauth_token'],
  $oauth->setToken($req_token['oauth_token'], $req_token['oauth_token_secret']);
  $acc_token = $oauth->getAccessToken('');

  $oauth->setToken($acc_token['oauth_token'], $acc_token['oauth_token_secret']);


  /* document returns body with the redirection url */

  /* make the redirect ourselves */

  echo $oauth->getLastResponse();
} catch (OAuthException $e) {
  echo '-- exception details --'.PHP_EOL;
  echo $e->getMessage().PHP_EOL;
  echo $e->lastResponse;


 [2009-04-06 14:36 UTC]
Thanks for the detailed bug report and investigation, this has been fixed in CVS.

Disable redirects and use the redirect_url provided by getLastResponseInfo(), relevant code:


/* new function in CVS */


$response_info = $oauth->getLastResponseInfo();

/* new redirect_url key in CVS (only set if there was a redirect) */
if(!empty($response_info["redirect_url"])) {


Please close the bug after verifying this works as expected for you.
 [2009-04-08 23:24 UTC] tjerk dot meesters at gmail dot com
Verified with:

$Id: oauth.c,v 1.32 2009/04/07 18:39:38 jawed Exp $
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Tue Jun 06 03:03:42 2023 UTC