Après le changement de domaine, 422 erreurs lors du téléchargement du fichier avec la progression du téléchargement Nginx Module

Question

Le module de progression du téléchargement de Nginx fonctionne depuis plusieurs mois sur divers serveurs Ubuntu 8.04, mais sur un de mes serveurs, j'obtiens 422 erreurs pour chaque fichier. J'essaie de télécharger (tous les fichiers fonctionnent sur tous les autres serveurs). Il n'y a rien dans mes journaux qui me dit quelque chose.

Ceci est la réponse que nginx me donne: "{ "état": "erreur", "statut": 422}"

La configuration du serveur est identique aux autres serveurs de travail.

Mais voici la partie vraiment étrange: Cela ne se produit quand j'ai changé le nom de domaine sur le serveur (j'ai changé le nom d'hôte, le fichier HOSTS, configs postfix, configuration du site nginx, et certaines parties de mon application Rails à toute utilisation le nouveau domaine, redémarré la machine, etc.) J'ai traversé toute la machine et n'ai trouvé aucune trace de l'ancien nom de domaine. Une fois que j'ai changé le domaine à l'ancien, les téléchargements de fichiers fonctionnent à nouveau.

Est-ce que quelqu'un sait comment je pourrais résoudre ce qui se passe ici? Je suis complètement perplexe.

Édition: J'ai recompilé nginx avec --with-debug, et voici quelques informations de débogage de mes journaux qui me semblent pertinentes ici.

 
2010/11/20 11:55:53 [debug] 8652#0: *13 test location: "upload_progress" 
2010/11/20 11:55:53 [debug] 8652#0: *13 using configuration "/upload_progress" 
2010/11/20 11:55:53 [debug] 8652#0: *13 http cl:-1 max:10485760 
2010/11/20 11:55:53 [debug] 8652#0: *13 generic phase: 2 
2010/11/20 11:55:53 [debug] 8652#0: *13 generic phase: 3 
2010/11/20 11:55:53 [debug] 8652#0: *13 post rewrite phase: 4 
2010/11/20 11:55:53 [debug] 8652#0: *13 generic phase: 5 
2010/11/20 11:55:53 [debug] 8652#0: *13 generic phase: 6 
2010/11/20 11:55:53 [debug] 8652#0: *13 access phase: 7 
2010/11/20 11:55:53 [debug] 8652#0: *13 access phase: 8 
2010/11/20 11:55:53 [debug] 8652#0: *13 post access phase: 9 
2010/11/20 11:55:53 [debug] 8652#0: *13 http set discard body 
2010/11/20 11:55:53 [debug] 8652#0: *13 upload-progress: get_tracking_id 
2010/11/20 11:55:53 [debug] 8652#0: *13 malloc: 080E7CA0:8 
2010/11/20 11:55:53 [debug] 8652#0: *13 upload-progress: get_tracking_id found header: b3fec 
2010/11/20 11:55:53 [debug] 8652#0: *13 reportuploads handler found id: b3fec 
2010/11/20 11:55:53 [debug] 8652#0: *13 upload-progress: find_node b3fec 
2010/11/20 11:55:53 [debug] 8652#0: *13 upload-progress: found node 
2010/11/20 11:55:53 [debug] 8652#0: *13 reportuploads found node: b3fec (rest: 0, length: 168849, done: 1, err_status: 422) 
2010/11/20 11:55:53 [debug] 8652#0: *13 http script copy: "{ "state" : "error", "status" : " 
2010/11/20 11:55:53 [debug] 8652#0: *13 http script var: "422" 
2010/11/20 11:55:53 [debug] 8652#0: *13 http script copy: " } 
" 
2010/11/20 11:55:53 [debug] 8652#0: *13 upload progress: state=1, err_status=422, remaining=168849, length=168849 
2010/11/20 11:55:53 [debug] 8652#0: *13 uploadprogress error-tracker error: 0 
2010/11/20 11:55:53 [debug] 8652#0: *13 HTTP/1.1 200 OK 
Server: nginx/0.7.67 
Date: Sat, 20 Nov 2010 19:55:53 GMT 
Content-Type: application/json 
Content-Length: 39 
Connection: keep-alive 
Expires: Thu, 01 Jan 1970 00:00:01 GMT 
Cache-Control: no-cache 

2010/11/20 11:55:53 [debug] 8652#0: *13 write new buf t:1 f:0 080DF1F0, pos 080DF1F0, size: 219 file: 0, size: 0 
2010/11/20 11:55:53 [debug] 8652#0: *13 http write filter: l:0 f:0 s:219 
2010/11/20 11:55:53 [debug] 8652#0: *13 http output filter "/upload_progress?" 
2010/11/20 11:55:53 [debug] 8652#0: *13 copy filter: "/upload_progress?" 
2010/11/20 11:55:53 [debug] 8652#0: *13 http postpone filter "/upload_progress?" BFEB0A78 
2010/11/20 11:55:53 [debug] 8652#0: *13 write old buf t:1 f:0 080DF1F0, pos 080DF1F0, size: 219 file: 0, size: 0 
2010/11/20 11:55:53 [debug] 8652#0: *13 write new buf t:1 f:0 080DF160, pos 080DF160, size: 39 file: 0, size: 0 
2010/11/20 11:55:53 [debug] 8652#0: *13 http write filter: l:1 f:0 s:258 
2010/11/20 11:55:53 [debug] 8652#0: *13 http write filter limit 0 
2010/11/20 11:55:53 [debug] 8652#0: *13 writev: 258 
2010/11/20 11:55:53 [debug] 8652#0: *13 http write filter 00000000 
2010/11/20 11:55:53 [debug] 8652#0: *13 copy filter: 0 "/upload_progress?" 
2010/11/20 11:55:53 [debug] 8652#0: *13 http finalize request: 0, "/upload_progress?" 1 
2010/11/20 11:55:53 [debug] 8652#0: *13 set http keepalive handler 
2010/11/20 11:55:53 [debug] 8652#0: *13 http close request 

Answer 1

Logiquement, si cela fonctionne ou ne fonctionne pas selon que le nom de domaine du serveur et vous n'êtes pas en train de changer quoi que ce soit d'autre en même temps et tout ce que vous avez écrit ci-dessus est correct, alors il y a seulement trois possibilités:

1. L'ancien nom de domaine est crypté, compressé ou compilé dans un fichier plutôt que d'être présent dans le texte brut, ce qui explique pourquoi représentant ne peut pas trouver.

2. Vous modifiez un paramètre de configuration pour l'ancien nom de domaine que vous ne devez pas modifier. c'est-à-dire plutôt qu'oublier de changer une config que vous devriez changer, vous oubliez pas changer une config que vous ne devriez pas changer.

3. Vous dépendez de quelque chose d'extérieur au serveur qui s'attend à voir une requête ou une requête contenant un domaine mais vous envoyez un domaine différent.

Ma meilleure estimation (combinant les points 2 et 3 ci-dessus) est que vous utilisez un service externe (service Web, le service d'authentification ou quelque chose de similaire) et avez oublié de mettre à jour cette configuration.