2012-05-01 18 views
8

Ho app per Facebook con flacone con nginx e uwsgi. Quando si riceve POST da facebook, ha sempre errore:Errore: readv() non riuscito (104: Connessione ripristinata dal peer) durante la lettura a monte

readv() failed (104: Connection reset by peer) while reading upstream 

Ma quando accedo mie applicazioni direttamente (con metodo GET), ha funzionato senza intoppi. Cosa ho fatto:

  1. Limite @ app.route con il metodo POST - non funziona.
  2. Aggiungi limite in wsgi: uwsgi_buffer_size (nel caso in cui la richiesta da facebook sia grande) e uwsgi_harakiri (nel caso in cui uwsgi fornisca il timeout prima di completare la richiesta) - non funziona.

Ho risolto il problema in django ma non riesco ancora a capire come implementare nel pallone. Qualcuno potrebbe aiutare per favore?

+0

la risposta è un po 'ridicola per me. Devo elaborare tutti i dati dei post, anche se il mio processo non sta facendo nulla. se "niente" non in request.form: pass. Funziona .. Btw, facebook apri l'app con la richiesta POST, quindi dovrei aggiungerla per ogni percorso. Ci deve essere un modo migliore per farlo .. – asofyan

+0

Se ci sono dati su un socket, devi leggerli (non ci sono altre scelte). Nella wiki del flask puoi trovare un middleware per aggirare questo problema comune sull'impostazione proxy: http://flask.pocoo.org/snippets/47/ uWSGI può aiutarti con l'opzione --post-buffering, ma è solo un scorciatoia, niente di magico. – roberto

+0

Grazie per lo snippet @roberto – asofyan

risposta

2

Questo è l'errore di uwsgi. È possibile ottenere di più da [uWSGI] Several bugs.

La soluzione semplice è che è necessario leggere il corpo POST di wsgi.input, anche se il corpo POST è nullo o non sono necessari i parametri POST.

+0

questo non ha nulla a che fare con uWSGI (e non è certamente un bug). Chiudere un socket senza leggere i dati in esso contenuti è un comportamento di programmazione errato. uWSGI può aiutarti (se non vuoi cambiare il tuo codice) nel buffering dei dati di post automaticamente tramite l'opzione --post-buffering. – roberto

+0

@roberto Grazie. Quando aggiungi l'opzione post-buffering nell'impostazione uwsgi, funziona. Ma in alcuni casi, ad esempio, la richiesta di post non ha parametri, non è necessario leggere il corpo del post da wsgi.input. Quindi non penso che sia l'errore dei programmatori. –

0

Il problema è che "upstream" (il processo effettivo che nginx sta inoltrando) sta chiudendo la connessione.

Nel mio caso, Django è il mio server Web e ho dovuto impostare DATA_UPLOAD_MAX_NUMBER_FIELDS in modo che fosse più grande perché c'erano troppi campi nella richiesta POST.

Problemi correlati