Nach Domain-Änderung, 422 Fehler beim Hochladen von Dateien mit Nginx Upload Progress Modul

Question

Ich hatte das Nginx Upload-Fortschritt-Modul für mehrere Monate auf verschiedenen Ubuntu 8.04 Servern arbeiten, aber auf einem meiner Server bekomme ich 422 Fehler für jede einzelne Datei Ich versuche hochzuladen (alle Dateien funktionieren auf jedem anderen Server). Es gibt nichts in irgendeinem meiner Protokolle, das mir irgendetwas sagt.

Dies ist die Antwort, dass nginx gibt mir: "{ "state": "error", "status": 422}"

Die Serverkonfiguration ist zu den anderen Arbeits Servern identisch.

Aber hier ist der wirklich seltsam Teil: Dies geschieht nur, wenn ich den Domain-Namen auf dem Server geändert (ich die Hostnamen geändert, Hosts-Datei, Postfix configs, nginx Standortkonfiguration, und Teile meiner Rails-Anwendung auf alle Nutzung die neue Domain, starte die Maschine neu, etc.) Ich habe die gesamte Maschine durchsucht und nirgendwo eine Spur vom alten Domainnamen gefunden. Sobald ich die Domain wieder auf die alte zurückstelle, funktioniert das Hochladen von Dateien wieder.

Weiß jemand, wie ich über die Fehlersuche gehen könnte, was hier vor sich geht? Ich bin völlig ratlos.

Bearbeiten: Ich kompilierte nginx mit --with-debug, und hier ist einige Debug-Informationen aus meinen Protokollen, die hier relevant erscheint.

 
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

Logisch, ob es funktioniert oder nicht funktioniert nur auf dem Domänennamen des Servers abhängig und Sie sind nichts anderes zur gleichen Zeit zu ändern und alles, was man oben ist geschrieben korrekt ist, dann gibt es nur drei Möglichkeiten:

1. Die alte Domain-Name wird verschlüsselt, komprimiert oder in eine Datei erstellt, anstatt im Klartext vorliegen, weshalb rep ist, kann es nicht finden.

2. Sie ändern eine Konfigurationseinstellung für den alten Domänennamen, den Sie nicht ändern sollten. dh anstatt zu vergessen, eine Konfiguration zu ändern, die Sie ändern sollten, vergessen Sie nicht ändern eine Konfiguration, die Sie nicht ändern sollten.

3. Sie haben eine Abhängigkeit von einem externen Server, der eine Anfrage erwartet, oder einer Anfrage, die eine Domain enthält, aber Sie senden eine andere Domain.

Meine beste Vermutung (Punkte 2 und 3 kombiniert) ist, dass Sie einigen externen Service (Web-Service, Authentifizierungsdienst oder etwas ähnliches) verwenden und vergessen, dass die Konfiguration zu aktualisieren.