nginx + fcgiwrapper спорадичен проблем: Доставя приложение/октет-поток вместо текст/обикновен

Нов съм в този форум. Това е първият ми въпрос.

Имам nginx-сървър + fcgiwrapper, настроен да изпълнява програми по заявка на потребител (без PHP).

За тестване имам прост bash скрипт, който показва променливите на средата и задава две бисквитки, вторият bash скрипт отпечатва "Hello World" като текст/обикновен, а друг bash скрипт отпечатва "Hello World" като текст/html.

Друга програма, написана на C, трябва да чете текст от stdin, да го анализира и да отпечатва текст, базиран на входа към stdout, който трябва да се показва като текст/обикновен в търсещия уеб браузър. (заявяващият браузър трябва да използва POST).

Въпреки това понякога той показва върнатия текст като "text/plain" (което трябва да направи), но понякога браузърът иска да изтегли върнатия текст, сякаш е "application/octet-stream".

Но ако тествам 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)


http nginx content-type fastcgi plaintext
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, с който можете да си играете, но когато изтеглите нещо двоичен текст/обикновен текст ще ви покаже боклук, не можете да смесвате и съпоставяте едното или другото. Ако изграждате бекенд, тогава в него трябва да зададете правилния тип, преди да доставите съдържанието.   -  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)


arrow_upward
0
arrow_downward

Чрез проба и грешка (с 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 се опитва да бъде интелигентен, като открива двоични данни и съответно променя заглавката, но това е предполагаем банкомат. - person itpp13; 28.05.2015
comment
Подателят е програмата, стартирана от fcgwirapper, нали? Освен това открих грешка в моята C програма. Вече не изпраща ^Q → Изискващият браузър вече не се опитва да изтегли изхода → Винаги е текст/обикновен, така че работи - person Cdrmoi; 29.05.2015