J'ai un ajax qui travaille sur un site en direct, il a cessé de travailler. L'AJAX devrait renvoyer une page, mais renvoie un 500 erreur (erreur de serveur interne) .
La chose étrange est que je peux naviguer et poster sur la page L'Ajax appelle, de sorte que la page ne fonctionne que via un appel Ajax ($ .post).
Une autre chose étrange est que cela fonctionne bien localement, mais pas vivre. Aussi, tous les autres ajax sur le site fonctionnent.
Quelqu'un a le plus de brouillard ce que cela pourrait être? Au fait, c'est tout JQuery avec CakePHP.
Les journaux d'erreur Apache disent:
"Terminé prématuré des en-têtes de script: Script PHP, référent ..."
EDIT 2 :
Tout s'est passé lorsque j'ai commuté le serveur sur SSL. Il dit au-dessus de l'erreur, puis du "port 80".
9 Réponses :
Vérifiez vos journaux d'erreur Apache et PHP la cause la plus courante de ce problème est le script en train de mourir avant d'envoyer l'ensemble complet d'en-têtes ou éventuellement du tout, au serveur. Pour voir si tel est le cas, essayez d'exécuter le script autonome d'une session interactive plutôt que sous forme de script sous le serveur. Si vous obtenez des messages d'erreur, ceci est presque certainement la cause du message «Fin prématuré des en-têtes de script». Même si la CGI fonctionne bien de la ligne de commande, rappelez-vous que l'environnement et les autorisations peuvent être différents lors de l'exécution sous le serveur Web. La CGI ne peut accéder que les ressources autorisées pour l'utilisateur et le groupe spécifiés dans votre configuration Apache. De plus, l'environnement ne sera pas le même que celui fourni sur la ligne de commande, mais il peut être ajusté à l'aide des directives fournies par mod_env. P> la deuxième cause la plus courante de ceci (à part les personnes non La sortie des en-têtes requises du tout) résulte d'une interaction avec la mise en mémoire tampon de sortie de Perl. Pour rendre Perl rincer ses tampons après chaque instruction de sortie, insérez les instructions suivantes autour des instructions d'impression ou d'écriture qui envoient vos en-têtes HTTP: P> CODE>! Il sera là-bas
{
local ($oldbar) = $|;
$cfh = select (STDOUT);
$| = 1;
#
# print your HTTP headers here
#
$| = $oldbar;
select ($cfh);
}
Oui .. Vous n'avez pas pensé au journal Apache, il est dit ... Fin de script prématuré: PHP-Script, référateur
La fin prématurée des en-têtes de script, ou probablement dans votre cas, aucun en-tête ne peut être causé par la même politique d'origine que j'ai notée ci-dessous.
Vous pouvez utiliser Fidler pour examiner ce que le serveur est renvoyé pendant ce $ .post . Il contiendra la page Web qui aurait été retournée si vous deviez exécuter la même méthode directement dans votre navigateur.
Ceci est irrégulier car l'erreur est dû au serveur interne, CakePHP
@RobertPitt - Quelle chose ridicule à dire. L'OP a dit "de sorte que la page ne fonctionne pas via un appel AJAX" - vous ne pensez pas que cela vaut la peine d'être examiné exactement ce qui est envoyé par l'appel Ajax et la comparant à ce que vous attendez de l'envoi?
L'OP a dit "500 erreur (erreur de serveur interne)". Il sait déjà ce que la page revient. pas un 404 Donc, il ne peut pas être l'URI, sa sorcière d'erreur interne signifie que Jsfiddle ne pourrait pas aider dans la matière
Mais intercepter avec violoneur défini sur Middle-Man Les HTTPS peuvent donner une vue sur la page d'erreur, qui aurait effectivement été utile et compte tenu des mêmes informations que l'on a été trouvée en recherchant les journaux du serveur.
Cette erreur est un peu problématique parce qu'elle peut être causée par tant de choses.
Quelle est votre page faire ...? Voici quelques suggestions.
Si votre page est comme une page complète automatique, vous passez donc un peu d'informations et obtenez une liste filtrée des résultats ... peut-être que votre script Ajax ne passe pas en arrière L'élément de données et votre page essaient de tout retourner. Les scripts PHP vraiment volumineux (c.-à-d. Les opérations intensives / récursives) peuvent causer cette erreur.
Le conseil normal de traiter avec cette erreur particulière est de revenir à une page stable, puis de commencer à ajouter des objets dedans - donc peut-être peut-être Pointez votre script Ajax sur une page qui ... ajoutez progressivement des blocs de votre code jusqu'à ce que vous ayez heurté un problème. Ma version 2 suggérée de cette page serait ... car cela vous permettra de vérifier ce qui se passe dans le formulaire post. Échec de tout ce qui précède, veuillez fournir les éléments suivants ... 1) une description de votre page PHP, ou peut-être un exemple du code.
2) le code JavaScript qui appelle la page PHP.
Peut-être que le site de production viole le Même stratégie d'origine .
L'URL du navigateur jusqu'à la troisième barre oblique, doit correspondre exactement à l'URL de votre poste AJAX, sinon les contraintes de sécurité des navigateurs pour JavaScript refuseront la réponse. Le serveur peut en réalité voir la demande et répondre correctement, mais le navigateur remit une chaîne vide à l'appel Ajax.
J'ai été témoin de XMLHTTPRÉQUEST Renvoyer un ready-statue de 4 (chargé), puis un statut de 0 (non défini) sans en-tête ou charge utile donnée une même violation d'origine. Vous penseriez que cela échouerait et donnerait un statut de niveau de 400 ou 500, mais ce n'est pas le cas.
Tout d'abord, cela n'a rien à voir avec les en-têtes JQuery, Ajax, Post, CakePHP ou HTTP. Le message d'erreur complet est "Fin de script prématuré", ce qui signifie que le processus PHP que Apache utilise pour exécuter le script PHP terminé de manière inattendue (c'est-à-dire avant que le processus PHP ait terminé sa partie du protocole de CGI rapide). Cela signifie généralement que le processus PHP s'est écrasé ou a provoqué une «défaillance de segmentation».
Les défauts de segmentation PHP peuvent être difficiles à dépanner et ils ne devraient jamais arriver; PHP ne devrait jamais écraser. La raison pour laquelle il se bloque peut être due à un certain nombre de choses. Peut-être que c'est une solution simple, cependant.
La première chose que je ferais est de désinstaller complètement PHP et d'installer la dernière version stable. Si vous exécutez PHP 5.3 et Windows, vous ne devez utiliser que les fichiers binaires VC6 (le package "VC6 X86 Safe Safe"); Le paquet VC9 entraînera un crash PHP lorsqu'il est utilisé par Apache. La réinstallation peut résoudre votre problème car les dlls / sons d'extension de sorties plus anciennes de PHP peuvent toujours exister dans votre répertoire d'extensions sur le serveur Live.
Si sous Windows et à l'aide de MySQL, la prochaine chose que je ferais est de vous assurer que le répertoire MySQL Si ces deux suggestions ne résolvent pas le problème, veuillez mettre à jour votre question avec des réponses aux réponses suivantes:
BIN est dans le serveur Live Server chemin . La raison de cela est de faire en sorte que libmysql.dll peut être "trouvé" par le système d'exploitation. Vous devriez être capable de ssh dans le serveur Live, tapez mysql -help et voir le message d'utilisation du client CLI MySQL CLI. Redémarrez Apache si vous ajoutez le répertoire MySQL BIN TO PATH .
dl ?
J'aimerais jeter mes 2 centimes, mais cela provient d'une direction légèrement différente et que vous pouvez avoir des ressources directes pour le dépannage - mais cela vaut la peine d'être réfléchie.
En règle générale, cependant, c'est une erreur PHP et nous pouvons exclure les problèmes secondaires du client. En plus de cela, dans mon travail de jour (dépannage du réseau), si quelque chose fonctionne puis s'arrête, je pense immédiatement à "ce qui a changé". Si vous n'avez rien ajouté au script et que vous n'ayez aucun moyen d'affecter le script au moment de l'exécution, je commencerais immédiatement à penser à «uh-oh, qu'est-ce qui se passe avec l'infrastructure». Ceci est particulièrement vrai si quelque chose fonctionne localement, mais pas sur Internet.
Avez-vous vérifié une mauvaise mémoire sur le serveur ou les mauvais habitants (si les mauvais habitants, cela expliquerait pourquoi il fonctionne une interface une seule et non). Avez-vous accès à cela ou est-il hébergé (votre chèque hôte peut-il)?
Ensuite, je commencerais à penser, d'accord, à la mémoire de la mémoire du serveur et que ce n'est pas probablement une nic défaillante, sinon cela échoue de manière sportive et à différents endroits. Toujours pourrait être en réseau, cependant. Existe-t-il un dispositif de sécurité qui peut mangler des paquets partout dans le mélange (Nids / Hids, waf, proxy, etc.) Voyez-vous des problèmes de réseau avec des paquets (DUPLICATES, hors de commande, ne pas fragmenter, etc.).
Je serai honnête, si quelqu'un a appelé mon bureau et que je décrivais vos problèmes, la première chose que je dirais, c'est "Vérifier les journaux IPS" environ 85% c'est le problème. Les faux positifs peuvent faire cela et tout ce qu'il faut est une mise à jour automatique sur le pare-feu ...
J'espère que cela aide.
pris de Autre que les raisons décrites dans le
Apache FAQ, le message de journal d'erreur
"Fin prématuré des en-têtes de script" pour
un script CGI (dans mon cas un script rubis
sur Dreamhost) peut aussi dire que le
Le répertoire contenant le script est
World-writable.
donc des autorisations de dossier comme DRWXR-XRWX
peut causer cette erreur. chmod 755 myDir
changerait ces autorisations à
drwxr-xr-x et tout va bien.
Je suppose que Apache / Souexec prend problème
avec des trucs en cours d'exécution que tout utilisateur pervers
peut éditer.
vaut la peine de vérifier les autorisations d'annuaire.
Sur une note distincte, vous dites que la question s'est produite lors de la modification du site pour utiliser SSL, mais le port 80. Le port 80. Le port 80 est utilisé pour le trafic HTTP standard, mais le port 443 est utilisé pour le trafic SSL - si le trafic se passe Via Port 80 Il pourrait y avoir une mauvaise configuration de serveur, un HTTP où il devrait y avoir un HTTPS ou un problème avec votre certificat. J'ai vu des erreurs similaires surviennent lorsqu'un certificat expire. Sont à la fois les URL (la page d'appel et le script) en utilisant SSL?
Vous devriez vérifier l'erreur PHP.Log, dans mon cas, j'avais défini type de cache avec Redis, mais cela ne fonctionne pas à juste titre.
J'ai aussi eu ce problème, dans ma solution de cas visant à remplacer le fichier php.ini avec le pur.
Je me demande s'il peut y avoir une sorte de mécanisme de journalisation sur le serveur où de telles "erreurs internes" sont enregistrées?
J'ai eu ces erreurs 500 avec Ajax, lorsque j'avais mal connecté des connexions à la DB, bien que cela a été dit avant, cela peut être presque n'importe quoi :)