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
    Аргументы = -u C: \ app \ app_wsgi.py
    FlushNamedPipe = 1
    RequestTimeout = 45
    IdleTimeout = 120
    ActivityTimeout = 30

Может кто-нибудь сказать, что не так или сказать мне, где я должен искать, чтобы узнать?

Все предложения с благодарностью ...

10.12.2008 14:04:51
5 ОТВЕТОВ

Простите, если это глупый вопрос, но я заметил эту строку в вашем конфигурационном файле:

Аргументы = -u C: \ app \ app_wsgi.py

Вы используете приложение WSGI или приложение FastCGI? Там является разница. В WSGI писать в stdout не очень хорошая идея. Ваша программа должна иметь объект приложения, который можно вызывать с помощью dict окружения и функции start_response (для получения дополнительной информации см. PEP 333 ). В любом случае, метод возврата вашего приложения будет возвращать итеративный объект, содержащий тело ответа, а не запись в stdout.

В любом случае, вам также следует рассмотреть возможность использования isapi-wsgi . Я никогда не использовал это сам, но я слышал хорошие вещи об этом.

1
11.12.2008 13:24:48
Совсем не глупый вопрос - я должен был упомянуть об этом в своем вопросе ... app_wsgi.pyвызывает библиотеку FastCGI, которая затем вызывает мое приложение WSGI. Это библиотека FastCGI, у которой проблемы с записью на стандартный вывод.
Ronan Klyne 11.12.2008 15:24:13

В Windows можно запустить процесс без действительного стандартного ввода и стандартного вывода. Например, если вы выполняете скрипт python с pythonw.exe, stdout является invdalid и если вы настаиваете на записи в него, он будет блокироваться после 140 символов или чего-то еще.

Запись в другое место, кроме stdout, выглядит как самое безопасное решение.

0
11.12.2008 15:01:21
Я уже использую python.exe, чтобы убедиться, что получаю правильный стандартный вывод. У меня есть действующий stdin, который может читать данные, но нет действительного stdout ... К сожалению, спецификация FastCGI говорит, что сервер ожидает от меня записи данных FastCGI на stdout, поэтому я не могу просто изменить способ, которым я делаю это ...
Ronan Klyne 11.12.2008 15:57:25

Следуя PEP 333, вы можете попытаться войти в [[wsgi.errors]], который обычно является регистратором самого веб-сервера, когда вы используете fastcgi. Конечно, это доступно только при вызове запроса, но не во время запуска приложения.

Вы можете получить пример в коде пилонов: http://pylonshq.com/docs/en/0.9.7/logging/#logging-to-wsgi-errors

0
25.08.2009 14:14:01

Вы должны использовать FastCGI? Если нет, вы можете попробовать метод ISAPI WSGI. Я имел успех, используя:

http://code.google.com/p/isapi-wsgi/

и также использовали PyISAPIe в прошлом:

http://sourceforge.net/apps/trac/pyisapie

1
7.10.2009 19:09:21
Не может ли более 1 URL быть навязанным самим пользователем или таким ограничением? Во всяком случае ... sourceforge.net/apps/trac/pyisapie
whatnick 1.10.2009 08:55:59
С тех пор, как я был новым пользователем, это было навязано, но я исправил это сейчас
Randy Syring 7.10.2009 19:09:43

Я считаю, что закрытый / недействительный стандартный вывод соответствует спецификации FastCGI :

Веб-сервер оставляет один файловый дескриптор, FCGI_LISTENSOCK_FILENO, открытым, когда приложение начинает выполнение. Этот дескриптор относится к сокету прослушивания, созданному веб-сервером.

FCGI_LISTENSOCK_FILENO равно STDIN_FILENO. Стандартные дескрипторы STDOUT_FILENO и STDERR_FILENO закрываются, когда приложение начинает выполнение. Надежный метод для приложения, чтобы определить, было ли оно вызвано с использованием CGI или FastCGI, - это вызов getpeername (FCGI_LISTENSOCK_FILENO), который возвращает -1 с errno, установленным в ENOTCONN для приложения FastCGI.

1
31.03.2011 00:05:02