Jump to content

Welcome! You're currently a Guest.

If you'd like to join in the Discussion, or access additional features in our forums, please sign in with your Evernote Account here. Have an Evernote Account but forgot your password? Reset it! Don't have an account yet? Create One! You'll need to set your Display Name before your first post.

Photo

EDAMTest (php) UserStore Failure


  • Please log in to reply
2 replies to this topic

#1 cdengler

cdengler

  • Pip
  • Title: Member
  • Group: Members
  • 4 posts

Posted 15 July 2012 - 09:29 PM

I'm trying to track down a strange issue -- everything works fine on both my development (localhost) systems and another remote server.

However in production (LightSpeed/PHP 5.4) it fails completely. Using a stripped-down version of the sample (exception handling omitted for brevity) even a simple version-check fails :

<?php
$userStoreHttpClient = new THttpClient('sandbox.evernote.com', '443', "/edam/user", 'https');
$userStoreProtocol = new TBinaryProtocol($userStoreHttpClient);
$userStore = new UserStoreClient($userStoreProtocol, $userStoreProtocol);
// do something simple and check the protocol version (returns true or false).
$versionOK = $userStore->checkVersion("Evernote EDAMTest (PHP)", 1, 21);
// <----- it never returns here. But gets stuck reading in ttransport.php
?>

I've been over the php.ini settings, cross-checked the firewall, and stepped through the lib files. It appears to get hung-up somewhere with the read.

I know it's not exactly an API issue, but has anyone seen this before?

#2 cdengler

cdengler

  • Pip
  • Title: Member
  • Group: Members
  • 4 posts

Posted 20 July 2012 - 02:40 AM

Following up my own post -- It took a test box and a packet sniffer, but I think I figured this out.

Evidently the headers (as set by flush() in THttpClient.php) were being stripped and/or overidden on their way out.

Expecting the POST to arrive with the requisite "Content-Type: application/x-thrift", it was instead showing up as "ContentType: application/x-www-form-urlencoded"; not good.

As a hack, the following appears to be a workaround:


ini_set("user_agent", "PHP/THttpClient\r\nAccept: application/x-thrift\r\nContent-Type: application/x-thrift");


Piggybacking the user_agent gets us the other headers as a bonus.

The reasons for this still have me completely baffled, but I hope this helps anyone who might be troubleshooting the same thing.

BTW, the post at http://stackoverflow.com/a/4249933 pushed me in the right direction.

#3 robertphyatt

robertphyatt

  • Pip
  • Title: Member
  • Group: Members
  • 2 posts

Posted 12 December 2012 - 08:10 AM

"The reasons for this still have me completely baffled, but I hope this helps anyone who might be troubleshooting the same thing."

Mission accomplished. Your hack fixed my problem. Thanks.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

Clip to Evernote