nginx 返回长度错误的 netstring?
nginx returning netstring with wrong length?
我在 mac 运行 最新的 OSX.
上通过 macports 安装了 nginx (nginx version: nginx/1.7.9
)
我配置了一个 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;
}
当我在 127.0.0.1/server
上执行 GET 请求时,我在我的 SCGI 服务器上看到以下内容:
633:CONTENT_LENGTH0REQUEST_METHODGETREQUEST_URI/serverQUERY_STRINGCONTENT_TYPEDOCUMENT_URI/serverDOCUMENT_ROOT/opt/local/htmlSCGI1SERVER_PROTOCOLHTTP/1.1REMOTE_ADDR127.0.0.1REMOTE_PORT62088SERVER_PORT80SERVER_NAMElocalhostHTTP_HOST127.0.0.1HTTP_CONNECTIONkeep-aliveHTTP_CACHE_CONTROLmax-age=0HTTP_ACCEPTtext/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8HTTP_USER_AGENTMozilla/5.0
(Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/40.0.2214.115
Safari/537.36HTTP_DNT1HTTP_ACCEPT_ENCODINGgzip, deflate,
sdchHTTP_ACCEPT_LANGUAGEen-US,en;q=0.8,End of file
问题是 netstring 的长度 633 与解释不符。如果我正确理解网络字符串 spec,633 应该是第一个 :
和最后一个 ,
之间的字符长度:
Any string of 8-bit bytes may be encoded as [len]":"[string]",". Here [string] is the string and [len] is a nonempty sequence of ASCII digits giving the length of [string] in decimal. The ASCII digits are <30> for 0, <31> for 1, and so on up through <39> for 9. Extra zeros at the front of [len] are prohibited: [len] begins with <30> exactly when [string] is empty.
例如,字符串 hello world!
被编码为 31 32 3a 68 65 6c 6c 6f 20 77 6f 72 6c 64 21 2c
,即 12:hello world!,
.
所以,我得到的长度有误。这怎么解释?
嗯,
十六进制<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>
这一行是一团糟:
For example, the string "hello world!" is encoded as <31 32 3a 68 65
6c 6c 6f 20 77 6f 72 6c 64 21 2c>, i.e., "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>
**中的十六进制是长度的第二个数字。
那你这个概念好吧,这个例子不好。
据我所知,您的示例响应长度正确。
根据这里的例子:
http://en.wikipedia.org/wiki/Simple_Common_Gateway_Interface
字段值前后都有<00>符号(十六进制代码为00的ASCII符号),例如:
REQUEST_METHOD <00>GET<00>
一旦我将缺失的空格添加到您的响应片段中 – 它很快就会恢复到 633 字节,如广告所示。
我想在将响应传递给我们的过程中,某个软件删除了 <00>,这是完全正常的行为?
无论如何,答案似乎是——您的 nginx 要么返回了正确的长度,要么您的响应在某处剥离了 <00>。
我在 mac 运行 最新的 OSX.
上通过 macports 安装了 nginx (nginx version: nginx/1.7.9
)
我配置了一个 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;
}
当我在 127.0.0.1/server
上执行 GET 请求时,我在我的 SCGI 服务器上看到以下内容:
633:CONTENT_LENGTH0REQUEST_METHODGETREQUEST_URI/serverQUERY_STRINGCONTENT_TYPEDOCUMENT_URI/serverDOCUMENT_ROOT/opt/local/htmlSCGI1SERVER_PROTOCOLHTTP/1.1REMOTE_ADDR127.0.0.1REMOTE_PORT62088SERVER_PORT80SERVER_NAMElocalhostHTTP_HOST127.0.0.1HTTP_CONNECTIONkeep-aliveHTTP_CACHE_CONTROLmax-age=0HTTP_ACCEPTtext/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8HTTP_USER_AGENTMozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36HTTP_DNT1HTTP_ACCEPT_ENCODINGgzip, deflate, sdchHTTP_ACCEPT_LANGUAGEen-US,en;q=0.8,End of file
问题是 netstring 的长度 633 与解释不符。如果我正确理解网络字符串 spec,633 应该是第一个 :
和最后一个 ,
之间的字符长度:
Any string of 8-bit bytes may be encoded as [len]":"[string]",". Here [string] is the string and [len] is a nonempty sequence of ASCII digits giving the length of [string] in decimal. The ASCII digits are <30> for 0, <31> for 1, and so on up through <39> for 9. Extra zeros at the front of [len] are prohibited: [len] begins with <30> exactly when [string] is empty.
例如,字符串 hello world!
被编码为 31 32 3a 68 65 6c 6c 6f 20 77 6f 72 6c 64 21 2c
,即 12:hello world!,
.
所以,我得到的长度有误。这怎么解释?
嗯,
十六进制<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>
这一行是一团糟:
For example, the string "hello world!" is encoded as <31 32 3a 68 65 6c 6c 6f 20 77 6f 72 6c 64 21 2c>, i.e., "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>
**中的十六进制是长度的第二个数字。
那你这个概念好吧,这个例子不好。
据我所知,您的示例响应长度正确。
根据这里的例子: http://en.wikipedia.org/wiki/Simple_Common_Gateway_Interface
字段值前后都有<00>符号(十六进制代码为00的ASCII符号),例如:
REQUEST_METHOD <00>GET<00>
一旦我将缺失的空格添加到您的响应片段中 – 它很快就会恢复到 633 字节,如广告所示。
我想在将响应传递给我们的过程中,某个软件删除了 <00>,这是完全正常的行为?
无论如何,答案似乎是——您的 nginx 要么返回了正确的长度,要么您的响应在某处剥离了 <00>。