CRM-12737 Handle cURL errors in class.api.php

    Details

    • Type: Bug
    • Status: Done/Fixed
    • Priority: Trivial
    • Resolution: Fixed/Completed
    • Affects Version/s: 4.3.3
    • Fix Version/s: 4.4.0
    • Component/s: CiviCRM API
    • Labels:
      None

      Description

      REST API requests which hit a cURL error end up trying to json_decode(FALSE).

        Attachments

          Activity

          [CRM-12737] Handle cURL errors in class.api.php
          Chris Burgess added a comment -

          Demo: Put CiviCRM behind a proxy or htpasswd auth in order to trigger a cURL error.

          xavier dutoit added a comment -

          Good point,

          Could you patch and add a test on curl errors to throw a proper error if civi server can't be reached?

          X+

          Chris Burgess added a comment -

          There's a pull req to go with this, but I didn't associate it correctly on Github. https://github.com/civicrm/civicrm-core/pull/925

          If we're in an external script which has only class.api.php and is failing to access the REST interface due to network issue, is there a better way of throwing a proper error than something like this?

          (object)array('is_error' => 1, 'error_message' => 'tada.wav')

          Chris Burgess added a comment -

          My Workflow menu is disabled so I can't associate pull reqs from GH. URL above.

          xavier dutoit added a comment -

          @chris,

          I've kept the error param, but added the standard "error_message"
          https://github.com/tttp/civicrm-core/commit/f95a0c25d254d82dc6bf5bbe14d4faac54e78345

          I've added another "better error handling" (if the server returns something but it isn't proper json)

          Chris Burgess added a comment -

          Looks good, I've added a small change as a subtask.

          I'm not sure about returning the contents of the request as $res->row_result ... are we inviting trouble there?

          xavier dutoit added a comment -

          The use case I have is: raw and row are way too close on the keyboard/braincells ;(

          taking that into account: what I've experienced: php spits on a syntax error. instead of having an empty return, we can have a chance to debug the error looking at the raw html returned.

          Might me better to only returns it if debug=1? Only meant for debug indeed

          Chris Burgess added a comment -

          What I was getting at was: if row_result was part of normal return value, putting the raw result there permits an API endpoint to return some string content which fails JSON parse but still gets through ... Unlikely, but if row_result is part of normal return, I wouldn't put raw data there.

          Sounds like its not part of normal return anyway?

          xavier dutoit added a comment -

          Hi,

          on error, the only normal results are
          is_error
          error_message
          we try to make it more computer friendly and include extra info, error_code/level type and whatever. but the general point is that it's only on error and less stuctured than the normal returns on success

          X+

          xavier dutoit added a comment -

          PRed (a long while ago)

            People

            • Assignee:
              xavier dutoit
              Reporter:
              Chris Burgess

              Dates

              • Created:
                Updated:
                Resolved: