Не могли бы вы предоставить реальный пример WSGIstart_response функция? (Веб-сервер предоставляет эту функцию для приложения wsgi)WSGI: какова цель функции start_response
Не знаю, что такое Цель введения start_response.
(Я читал как 10 идентичных текстов о стандарте WSGI. Все они говорят, что «стандарт WSGI - это ...» Ни один из них не говорит: «WSGI разработан таким образом , чтобы ...» :()
могли бы вы предоставить реальную жизнь пример WSGI
start_response()функции?
Ну, start_response() функция mod_wsgi определяется на line 2678 of mod_wgsi.c
Ни один из них не говорят «WSGI разработан таким образом, чтобы ...»
Там, кажется, не будет много обоснования этого аспекта конструкции WSGI в PEP3333. Глядя через web-sig mailing list archives, я наткнулся на this message ...
Некоторого время назад я возражал решение удалить start_response функцию из следующей версии WSGI, используя в качестве обоснования того, что без start_callable асинхронного расширения невозможно поддержка.
Теперь я обнаружил, что удаление start_response также сделает невозможным для поддержки сопрограмм (или, по крайней мере, некоторых сопрограмм ).
[...]
... который начал длинную нить о обосновании этой части реализации, которая может быть стоит прочитать.
Если вы действительно хотите знать происхождение этого аспекта интерфейса WSGI, вы должны прочитать много сообщений между this initial draft в декабре 2003 года, и this later draft в августе 2004.
Обновление
Как это совместимо с этим другим протоколом?
Я не совсем уверен, что вы имеете в виду. Игнорируя все ранние черновики, интерфейс WSGI 1.x можно использовать двумя разными способами.
'осуждается' метод ...
def application(environ, start_response):
write = start_response(status, headers)
write('content block 1')
write('content block 2')
write('content block 3')
return None
... и 'рекомендуется' метод ...
def application(environ, start_response):
start_response(status, headers)
return ['content block 1',
'content block 2',
'content block 3']
Предположительно, вы можете использовать оба, с ...
def application(environ, start_response):
write = start_response(status, headers)
write('content block 1')
return ['content block 2',
'content block 3']
... но в результате поведение может быть неопределенным.
Взглядами this blog post, новый метод WSGI 2.x рассматривается является ...
def application(environ):
return (status,
headers,
['content block 1',
'content block 2',
'content block 3'])
... который устраняет start_response() отозваны, и, очевидно, write() отозваны, но нет указание на то, когда (или даже если) это, скорее всего, приведет к нарушению WSGI 1.x.
Я нашел старую нить, которая может объяснить, почему.
Почему там start_response, а затем отдельный возврат?
Одна из причин заключается в том, что он позволяет писать приложение в качестве генератора. Но что более важно, это необходимо для поддержки «write()» для обратной совместимости с существующими фреймворками, и это в значительной степени «причина убийцы», она структурирована так, как она есть. Это особое новшество - детище Тони Лаундса, хотя и не мое. В моей первоначальной концепции WSGI приложение получило поток вывода и просто написало заголовки и все для него.
Пожалуйста, не позволяйте асинхронным сторонникам мутить воды над тем, с чем начинался start_response(). Одна из основных причин заключалась в том, чтобы позволить серверу возвращать функцию write(), предназначенную для поддержки существующих веб-приложений Python, которые использовались для вызова функции write() для создания контента. Это спасло их от перезаписи, чтобы вернуть итерабельность. –
@GrahamDumpleton Ну, учитывая, что я не участвовал в процессе проектирования, и я не мог потрудиться, чтобы прочитать каждое сообщение в архиве веб-сиггов, я мог бы реально только спекулировать. Тем не менее, похоже, что исходный проект, который я связал, который предложил использовать функцию 'def runCGI (input, output, errors, environ)', также предоставил бы такой вызываемый через 'output.write()'. Это выглядело больше похоже на некоторое возражение против того, чтобы веб-приложение вручную записывало строку «HTTP/1.1 200 OK», и заголовки ответов сами. – Aya
Меня там тоже не было, и вы откопали вещи, которые я даже не читал раньше. Версия runCGI была бы до того, как она была изменена для возврата итерации, поэтому вывод был исключительно посредством write(). В этот момент они могли бы отбросить write(), что и предложили решения WSGI 2+. В WSGI 2+, где write() не требуется, start_response() также исчезает. Не нужно больше висеть на write(), потому что очень старые приложения, зависящие от возможности записи write(), больше не существуют или были переписаны, чтобы теперь возвратить итерабельность для ответа. –