nginx + fcgiwrapper спорадическая Проблема: доставляет application / octet-stream вместо text / plain

Я новичок на этом форуме. Это мой первый вопрос.

У меня есть nginx-server + fcgiwrapper, настроенный для запуска программ по запросу пользователя (без PHP).

Для тестирования у меня есть простой сценарий bash, который отображает переменные среды и устанавливает два файла cookie, второй сценарий bash печатает «Hello World» как text / plain, а другой сценарий bash печатает «Hello World» как text / html.

Другая программа, написанная на C, должна читать текст из stdin, анализировать его и печатать текст на основе ввода в stdout, который должен отображаться как text / plain в запрашивающем веб-браузере. (запрашивающий браузер должен использовать POST).

Однако иногда он отображает возвращенный текст как «текст / простой» (что он должен делать), но иногда браузер хочет загрузить возвращенный текст, как если бы это было «приложение / октет-поток».

Но, если я тестирую C-программу в подготовленной среде

Environment Variables:
CONTENT_LENGTH=30
REQUEST_METHOD=POST
HTTP_COOKIE=NAME=TEST; ID=200

он работает каждый раз, ошибок не показывает и вначале печатает:

Content-type: text/plain (plus two newlines)

Я обнаружил, что в зависимости от длины содержимого это иногда работает, а иногда нет. (Это происходит только тогда, когда программа запускается через веб-браузер.) В Firefox, используя инструменты разработчика, я мог видеть, что ответы Content-type были

application/octet-stream

и если я сохраню его, это окажется текстовый файл, содержащий текст, который должен был отображаться непосредственно в браузере. Что я делаю неправильно?

Изменить: я уже безуспешно искал похожие проблемы + все остальное работает отлично + Это также происходит с разными браузерами (Epiphany, lynx, internet explorer в Windows)


person Cdrmoi    schedule 27.05.2015    source источник
comment
Если я изменю программу C на вывод Content-type: text/html, она будет работать. Но я хочу Content-type: text/plain!   -  person Cdrmoi    schedule 27.05.2015
comment
внутри блока местоположения установите default_type text / plain;   -  person itpp13    schedule 28.05.2015
comment
Спасибо за ответ. Если я сделаю то, что вы предложили (установив default_type text/plain в nginx.conf), ошибка все равно останется. Но, если я загляну в загруженный документ, там есть управляющие символы, которых там не должно быть: ^Q or (iso) DC1. Может в этом проблема? Извлечение из nginx.conf: include /etc/nginx/mime.types; #default_type application/octet-stream; default_type text/plain; Или мне нужно добавить text/plain в mime.types?   -  person Cdrmoi    schedule 28.05.2015
comment
В / conf есть файл mime.types, с которым вы можете играть, однако, когда вы загружаете что-то двоичное, text / plain покажет вам мусор, вы не можете смешивать и сопоставлять его то или другое. Если вы создаете серверную часть, то в ней вам необходимо установить правильный тип перед доставкой контента.   -  person itpp13    schedule 28.05.2015
comment
В порядке. Я сделал это. Однако похоже, что мои изменения не действуют. Кажется, что nginx или fcgiwrapper (я все еще новичок в этом) иногда просто игнорируют строку Content-type: text/plain, напечатанную C-программой.   -  person Cdrmoi    schedule 28.05.2015
comment
Если ваша программа всегда генерирует этот заголовок, вам следует удалить строку конфигурации содержимого из nginx.conf. Также используйте curl -h в качестве инструмента командной строки, чтобы увидеть, что на самом деле отправляется в заголовках и кем.   -  person itpp13    schedule 28.05.2015
comment
Это сработало! Спасибо.   -  person Cdrmoi    schedule 28.05.2015


Ответы (1)


Методом проб и ошибок (с помощью curl + firefox-dev-tools) я обнаружил, что персонаж

0x11

в сочетании с: Content-type: text/plain
заставляет nginx доставлять Content-type: application/octet-stream.

Я не знаю, почему это происходит, но я обнаружил, что программа C выдает ошибку, потому что она печатает 0x11, ^Q или dc1. Это явление также происходит с файлами, содержащими этот символ.

person Cdrmoi    schedule 28.05.2015
comment
Это происходит потому, что куда-то отправляется двоичный файл, в то время как отправитель сообщает получателю, что это обычный текст. Похоже, что отправитель ошибся при отправке неправильного типа. В случае прокси / nginx может оказаться, что nginx пытается проявить смекалку, обнаруживая двоичные данные и соответствующим образом изменяя заголовок, но это предположение ATM. - person itpp13; 28.05.2015
comment
Отправителем является программа, запущенная fcgwirapper, не так ли? Кроме того, я обнаружил ошибку в своей программе на C. Теперь он больше не отправляет ^Q → Запрашивающий браузер больше не пытается загрузить вывод → Он всегда текстовый / простой, поэтому он работает - person Cdrmoi; 29.05.2015