Python FastCGI под IIS - проблемы с записью стандартного вывода
У меня очень специфическая проблема в моем коде Python FastCGI - sys.stdout имеет файловый дескриптор «-1», поэтому я не могу писать в него. Я проверяю это в первой строке моей программы, поэтому я знаю, что это не мой код, который меняет это.
Я пробовал sys.stdout = os.fdopen(1, 'w'), но все, что там написано, не попадет в мой браузер.
Это же приложение без проблем работает под Apache.
Я использую предоставленное Microsoft расширение FastCGI для IIS, описанное здесь: http://learn.iis.net/page.aspx/248/configuring-fastcgi-extension-for-iis60/
Я использую эти настройки в fcgiext.ini:
ExePath=C:\Python23\python.exe
Arguments=-u C:\app\app_wsgi.py
FlushNamedPipe=1
RequestTimeout=45
IdleTimeout=120
ActivityTimeout=30
Может ли кто-нибудь сказать, что не так, или сказать, где я должен искать, чтобы узнать?
Все предложения очень признательны ...
Ответы 5
Простите меня, если это глупый вопрос, но я заметил эту строку в вашем файле конфигурации:
Arguments=-u C:\app\app_wsgi.py
Вы используете приложение WSGI или приложение FastCGI? Там является разница. В WSGI запись в стандартный вывод - не лучшая идея. В вашей программе должен быть объект приложения, который можно вызвать с помощью команды окружения и функции start_response (для получения дополнительной информации см. PEP 333). В любом случае метод возврата вашего приложения будет заключаться в возврате итерируемого объекта, содержащего тело ответа, а не в записи в стандартный вывод.
В любом случае вам также следует рассмотреть возможность использования Isapi-WSGI. Сам никогда не пользовался, но слышал о нем хорошие отзывы.
В Windows можно запустить процесс без действительных stdin и stdout. Например, если вы выполняете скрипт python с pythonw.exe, стандартный вывод будет invdalid, и если вы настаиваете на его записи, он будет заблокирован после 140 символов или чего-то подобного.
Запись в другое место назначения, отличное от stdout, выглядит самым безопасным решением.
Я уже использую python.exe, чтобы убедиться, что получаю действительный стандартный вывод. У меня есть действительный stdin, который может читать данные, но не действительный stdout ... К сожалению, в спецификации FastCGI говорится, что сервер ожидает от меня записи данных FastCGI на stdout, поэтому я не могу просто изменить способ Это...
Следуя PEP 333, вы можете попытаться войти в Environment ['wsgi.errors'], который обычно является регистратором самого веб-сервера, когда вы используете fastcgi. Конечно, это доступно только при вызове запроса, но не во время запуска приложения.
Вы можете получить пример в коде пилонов: http://pylonshq.com/docs/en/0.9.7/logging/#logging-to-wsgi-errors
Вам обязательно использовать FastCGI? Если нет, вы можете попробовать метод ISAPI WSGI. Я успешно использовал:
http://code.google.com/p/isapi-wsgi/
а также использовали PyISAPIe в прошлом:
http://sourceforge.net/apps/trac/pyisapie
Является ли не более 1 URL-адреса добровольным ограничением или ограничением, наложенным SO? В любом случае ... sourceforge.net/apps/trac/pyisapie
ТАК наложено, так как я был новым пользователем, но я исправил это сейчас
Я считаю, что закрытый / недействительный стандартный вывод соответствует Спецификация FastCGI:
The Web server leaves a single file descriptor, FCGI_LISTENSOCK_FILENO, open when the application begins execution. This descriptor refers to a listening socket created by the Web server.
FCGI_LISTENSOCK_FILENO equals STDIN_FILENO. The standard descriptors STDOUT_FILENO and STDERR_FILENO are closed when the application begins execution. A reliable method for an application to determine whether it was invoked using CGI or FastCGI is to call getpeername(FCGI_LISTENSOCK_FILENO), which returns -1 with errno set to ENOTCONN for a FastCGI application.
Вовсе не глупый вопрос - я должен был упомянуть об этом в своем вопросе ...
app_wsgi.pyвызывает библиотеку FastCGI, которая затем вызывает мое приложение WSGI. Это у библиотеки FastCGI проблемы с записью в стандартный вывод.