PHP curl mis d'erreur 500

J'ai un curl mis requête qui fonctionne très bien sur mon localhost, mais sur le serveur live il jette en arrière une erreur 500. Voici mon code:

public static function send( $xml )
{
    $xml = str_replace( "\n", "", $xml );

    //Write to temporary file
    $put_data = tmpfile();
    fwrite( $put_data, $xml );  
    fseek( $put_data, 0 );

    $options = array(
            CURLOPT_URL => 'http://*****************/cgi-bin/commctrl.pl?SessionId=' . Xml_helper::generate_session_id() . '&SystemId=live',
            CURLOPT_RETURNTRANSFER => 1,
            CURLOPT_HTTPHEADER => array( 'Content-type: text/xml' ),
            CURLOPT_PUT => TRUE,
                CURLOPT_INFILE => $put_data,
            CURLOPT_INFILESIZE => strlen( $xml )
        );

        $curl = curl_init();
        curl_setopt_array( $curl, $options );
        $result = curl_exec( $curl );
        curl_close( $curl );

        return $result;
    }

J'ai curl est activé sur le serveur!

Quelqu'un a une idée pourquoi il ne fonctionne pas sur le serveur? Je suis en hébergement mutualisé si cela aide.

J'ai aussi activé les rapports d'erreur en haut du fichier, mais pas d'erreurs spectacle après la boucle est terminée. Je viens d'obtenir le générique de la page d'erreur 500.

Grâce

Mise à JOUR:

J'ai été en contact avec le client et ils ont confirmé que l'information qui est envoyé est reçu par eux et inséré dans leur système de back-office. Donc, il doit être quelque chose à voir avec la réponse qui en est la cause. C'est un petit bloc de code xml qui est supposé être retourné.

UNE AUTRE MISE À JOUR

J'ai essayé le même script sur un serveur différent et heroku et j'obtiens toujours le même résultat.

UNE AUTRE MISE À JOUR

Je pense que j'ai peut-être trouvé la route de la question. Le script semble expirer à cause d'un timeout sur FastCGI et parce que je suis sur un hébergement mutualisé, je ne peux pas le changer. Quelqu'un peut-il confirmer cela?

DERNIÈRE MISE À JOUR

Je suis entré en contact avec mon fournisseur d'hébergement et ils ont confirmé que le script a été expirer en raison de la valeur de délai d'expiration sur le serveur et non pas celui que je peux y accéder avec n'importe quel fonction PHP ou la fonction ini_set().

L'erreur 500 est généré sur le serveur, ici http://************/cgi-bin/commctrl.pl?SessionId=..., il n'est pas généré par la boucle. Ce que vous devez faire est de regarder dans le journal des erreurs sur votre éloignés de l'hôte, et non pas sur celui qui exécute le script curl.
Merci pour les commentaires, comment se fait-il fonctionne sur mon localhost? Ne serait-il pas renvoyer une erreur 500, peu importe où je y accéder???
Est-ce que votre non-serveur local ont curl lib installé?
Oui, c'est fait, j'ai parlé dans le post
vous avez die( $result ); avant le return $result;

OriginalL'auteur David Jones | 2013-11-18

  1. 6

    Si l'erreur est, comme vous le penser il est, de le faire avec un script de délai d'attente et vous n'avez pas accès au php.fichier ini - il y a une solution facile

    simplement utiliser set_time_limit(INT) où INT est le nombre de secondes, au début de votre script pour remplacer les paramètres du php.fichier ini

    La fixation d'un délai d'attente de set_time_limit(128) devrait résoudre tous vos problèmes et il est généralement accepté comme une limite supérieure raisonnable

    Plus d'informations peuvent être trouvées ici http://php.net/manual/en/function.set-time-limit.php

    Salut, j'ai essayé et cela n'a pas fonctionné. Je suis entré en contact avec mon fournisseur d'hébergement et ils ont confirmé que le script a été expirer en raison de la valeur de délai d'expiration sur le serveur et non pas celui que je peux y accéder avec n'importe quel fonction PHP ou la fonction ini_set(). Merci quand même.
    Cela veut-il dire il n'y a rien que vous pouvez faire?
    Oui, nous avons besoin de déplacer le site de notre serveur dédié, l'API nous sommes l'accès est extrêmement lent. Il prend 49 secondes pour obtenir une réponse et le max de temps d'exécution est de 30 sur notre hébergement mutualisé.
    Suce, quel gaspillage de 250 points de rep. Au moins vous l'avez compris

    OriginalL'auteur Dan Green-Leipciger

  2. 3

    Voici quelques choses à essayer:

    1. Supprimer la variabilité dans le script pour tester, coder en dur l'id de session, de sorte que le curl curl est le même. Vous ne pouvez pas fiable tester quelque chose, si elle change à chaque fois que vous l'exécutez.

    2. Essayez d'utiliser curl directement à partir de la ligne de commande, via quelque chose comme curl http://*****************/cgi-bin/commctrl.pl?SessionId=12345&SystemId=live. Cela va vous montrer si le problème est vraiment lié à l'ordinateur lui-même, ou quelque chose à faire avec PHP.

    3. Vérifier les logs de votre serveur, probablement quelque chose comme /var/log/apache/erreur.journal selon le système d'exploitation de votre serveur utilise. Regardez également le journal d'accès, de sorte que vous pouvez voir si vous êtes en train de recevoir la même demande.

    4. Enfin, si vous avez vraiment à court d'idées, vous pouvez utiliser un programme comme wireshark ou tcpdump/WinDump pour surveiller la connexion, de sorte que vous pouvez comparer les paquets envoyés à partir de chaque ordinateur. Cela vous donnera une idée de la façon dont ils sont différents - sont-ils déformés par un pare-feu? Est php en ajoutant des en-têtes supplémentaires à l'un d'eux? Sont différents CURL par défaut causant des données différentes pour être inclus?

    1. L'ID de session doit changer pour chaque demande. Même si j'ai essayé un peu de temps avec elle codé en dur et ils ont tous échoué. 2. Je l'ai essayé et il a renvoyé la réponse attendue. Est-ce à dire que le serveur est le problème? 3. Le journal des erreurs et le journal d'accès ne montrent rien pour nous aider. 4. J'ai installé wireshark, bel outil tbh. J'ai vérifié la réponse lors de l'envoi de requêtes à partir de mon localhost et ils sont exected ce que j'attends. Suis-je capable de voir ce qui vient depuis le serveur nous sont d'avoir des problèmes??
    1. Si la session doit changer à chaque requête, puis peut-être le problème, c'est que l'id de session qu'il génère est mal? 2. Si la ligne de commande curl fonctionne et le php n'est pas le cas, alors le problème est avec le code php; si la ligne de commande ne fonctionne pas, alors le problème est avec la connexion entre les ordinateurs. 4. Oui, Wireshark devrait montrer les paquets envoyés et reçus, il ne peut tout simplement être source de confusion pour le configurer.

    OriginalL'auteur Benubird

  3. 1

    Je soupçonne que votre serveur ne prend pas en charge tmpfile(). Juste pour vérifier:

    public static function send( $xml ) {
$xml = str_replace( "\n", "", $xml );

//Write to temporary file
$put_data = tmpfile();
if (!$put_data) die('tmpfile failed');
...

    Si vous êtes sur GoDaddy serveur de vérifier cela... https://stackoverflow.com/questions/9957397/tmpfile-returns-false-on-godaddy-server

    Salut merci pour les commentaires, j'ai tester ce et l'a trouvé n'est pas la cause du problème.

    OriginalL'auteur Amit Kriplani

  4. 0

    Serveur qui montre en fait la 500 ? à partir de votre code, il semble que le serveur local plutôt que de la distance.
    changement

    public static function send( $xml )
{

    à

    public static function send( $xml )
{
    error_reporting(E_ALL);
    if(!function_exists('curl_exec')) {
        var_dump("NO CURL");
        return false;
     }

    ?

    Pour commencer, il vous manque un point virgule sur le var_dump et j'ai dit que curl est activé dans le post. Merci.
    Vérifiez votre journal des erreurs d'apache ?
    Ouai, l'un pour notre serveur n'a pas d'indiquer une erreur s'est produite lors de la soumission de données
    le rapport d'erreur montrer plus ? À partir du code que vous avez posté votre de ne jamais obtenir le code d'état à partir de là server. Juste le outpu. Est-il une erreur de traitement du xml ?
    Non, c'est l'exécution de roulage, ce qui déclenche l'erreur 500. Si je supprime le curl_exec() appeler le script fonctionne très bien. J'ai le rapport d'erreurs, mais cela montre tout de même le générique de 500 erreur interne page.

    OriginalL'auteur exussum

  5. 0

    Ce n'est presque certainement PAS le php paramètre de délai d'attente.
    Si vous utilisez FastCGI comme vous l'avez dit, alors vous devez éditer ce fichier:

    /etc/httpd/conf.d/fcgid.conf

    Et le changement:

    FcgidIOTimeout 3600

    Alors:

    service httpd restart

    Cela me rendait folle pour 3 jours. Le haut voté réponse à cela est faux!

    Oui je sais ce n'est pas le PHP paramètre de délai d'attente, il a été établi quelque part dans les commentaires. Je l'ai résolu en mettant sur un serveur dédié où je suis en mesure de modifier les paramètres.

    OriginalL'auteur wbinky