nginx возвращает netstring с неправильной длиной?

Я установил nginx (nginx version: nginx/1.7.9) через macports на моем Mac под управлением последней версии OSX.

Я настроил URI для использования SCGI:

location /server {
    include /Users/ruipacheco/Projects/Assorted/nginx/conf/scgi_params;
    scgi_pass unix:/var/tmp/rpc.sock;
    #scgi_pass 127.0.0.1:9000;
}

И когда я делаю запрос GET на 127.0.0.1/serverЯ вижу следующее на моем сервере SCGI:

633: CONTENT_LENGTH0REQUEST_METHODGETREQUEST_URI / serverQUERY_STRINGCONTENT_TYPEDOCUMENT_URI / serverDOCUMENT_ROOT / Opt / местные /htmlSCGI1SERVER_PROTOCOLHTTP/1.1REMOTE_ADDR127.0.0.1REMOTE_PORT62088SERVER_PORT80SERVER_NAMElocalhostHTTP_HOST127.0.0.1HTTP_CONNECTIONkeep-aliveHTTP_CACHE_CONTROLmax-возраст =0HTTP_ACCEPTtext/ HTML, приложение / XHTML + XML, приложение / XML; д = 0,9, изображение / WebP,/;q=0,8HTTP_USER_AGENTMozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537,36 (KHTML, как Gecko) Chrome/40.0.2214.115 Safari/537.36HTTP_DNT1HTTP_ACCEPT_ENTCHEGTENGDGTGTGTGTGTHTGTGTGTGTGTHTGTGHTGTGTGTKTKTKTKHTKTKTHTKTG файла

Проблема в том, что длина netstring, 633, не соответствует интерпретации. Если я правильно понимаю спецификацию netstrings, 633 должна быть длиной символов между первым : и последнее ,:

Любая строка из 8-битных байтов может быть закодирована как [len]":"[string]",". Здесь [string] - строка, а [len] - непустая последовательность цифр ASCII, дающая длину [string] в десятичном виде. Цифры ASCII: <30> для 0, <31> для 1 и т. Д. До <39> для 9. Запрещены дополнительные нули в начале [len]: [len] начинается с <30> именно тогда, когда [ строка] пуста

Например, строка hello world! кодируется как 31 32 3a 68 65 6c 6c 6f 20 77 6f 72 6c 64 21 2cт.е. 12:hello world!,,

Итак, я получаю неправильную длину. Как это можно объяснить?

Источник

2 ответа

Решение

Насколько я могу судить, ваш пример ответа имеет правильную длину.

В соответствии с примером здесь: http://en.wikipedia.org/wiki/Simple_Common_Gateway_Interface

Значениям поля предшествует и следует символ <00> (символ ASCII с шестнадцатеричным кодом 00), например:

REQUEST_METHOD <00>GET<00>

Как только я добавил недостающие пробелы в ваш фрагмент ответа - он быстро вернулся к 633 байтам, как было объявлено.

Я предполагаю, что где-то в процессе передачи этого ответа нам здесь, какое-то программное обеспечение лишено <00>, что является абсолютно нормальным поведением?

В любом случае, ответ вроде бы - ваш nginx либо возвращает правильную длину, либо ваш ответ где-то удаляет <00>.

Источник

Что ж,

Шестнадцатеричный <31 32 3a 68 65 6c 6c 6f 20 77 6f 72 6c 64 21> в ASCII является "12:hello world!" (без кавычек) и длина 12 (привет мир!)

И этот <31 32 3a 68 65 6c 6c 6f 20 77 6f 72 6c 64 21 2c> в примере это неверно (по крайней мере, оно не соответствует норме nginx.)(поскольку внутренняя длина равна 13, а длина, указанная в шестнадцатеричном формате, равна 12):

ASCII "12:hello world!," должно быть "13:hello world!," и в шестнадцатеричном <31 33 3a 68 65 6c 6c 6f 20 77 6f 72 6c 64 21 2c>

Эта строка беспорядок:

Например, строка "Привет, мир!" кодируется как <31 32 3a 68 65 6c 6c 6f 20 77 6f 72 6c 64 21 2c>, т. е. "12:hello world!,".

OK) 12:hello world!  ---> <31 *32* 3a 68 65 6c 6c 6f 20 77 6f 72 6c 64 21>

KO) 12:hello world!, ---> <31 *32* 3a 68 65 6c 6c 6f 20 77 6f 72 6c 64 21 2c>

OK) 13:hello world!, ---> <31 *33* 3a 68 65 6c 6c 6f 20 77 6f 72 6c 64 21 2c>

Гекс внутри ** - это второе число длины.

Тогда ваше представление об этом Хорошо, пример плохой.

Источник
Другие вопросы по тегам