2015-10-12 18 views

risposta

7

Il server WSGI di Werkzeug non è destinato all'uso in produzione. Viene fornito come comodità durante lo sviluppo. Non è stato sviluppato pensando alla sicurezza o alle prestazioni (per impostazione predefinita gestisce solo una richiesta alla volta). Utilizzare un server di applicazioni WSGI reale come uWSGI o Gunicorn per le prestazioni e inoltrarlo tramite un server Web reale come Nginx per prestazioni e sicurezza. I server Web sono in grado di rispondere alle richieste/risposte di accodamento, possono servire allo stesso tempo contenuto statico e di altro tipo e sono progettati per gestire SSL. I server WSGI sono in grado di coordinare più richieste in tutta l'app in modo efficiente. Werkzeug è stato progettato come libreria WSGI, non come server Web o server WSGI.

Il docs indica direttamente di non utilizzare il server di sviluppo in produzione.

È possibile utilizzare il server integrato durante lo sviluppo, ma è necessario utilizzare un'opzione di distribuzione completa per le applicazioni di produzione. (Non utilizzare il server di sviluppo integrato nella produzione.)

Inoltre, i server web come root (quindi cadere uscita), in modo da poter ascoltare sulle porte standard 80 e 443. Si dovrebbe mai eseguire un applicazione come root, e quindi si sarebbe in grado di collegarsi solo a porte superiori a 1024, quindi gli utenti dovrebbero conoscere la porta piuttosto che il dominio.

-2

"Non si dovrebbe mai eseguire un'applicazione come root"

questo non ha senso di sorta. nginx per impostazione predefinita viene eseguito anche come root. se si esegue il pallone come root, almeno si può servire la porta 80, che è molto difficile da ottenere in caso contrario.

+2

Questa è la tua opinione, anche molto male potrei aggiungere. – ishaan

Problemi correlati