我正在尝试以下方法:
$ curl -X GET "http://somewhere:14000/webhdfs/v1/user/frb?op=liststatus&user.name=frb" -H "X-Auth-Token: xxxxxxxx"
curl: (56) Recv failure: Connection reset by peer
在第一阶段,我虽然这是服务器的问题,但是嗅探远程端的流量,我发现重置是由curl
发送的!为什么呢?
一些有用的信息:
$ curl --version
curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.19.1 Basic ECC zlib/1.2.7 libidn/1.28 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz
$ cat /etc/redhat-release
CentOS Linux release 7.1.1503 (Core)
$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain DOCKER (0 references)
target prot opt source destination
有关正在发生的事情的任何想法?提前谢谢!
编辑1
根据@nos的建议,我将详细介绍content-length
标头和发送的实际有效负载长度:
有趣的是,似乎有些不正确......
编辑2
打印整个Http响应。第一个块被延迟为1829字节长度(725十六进制),但计算有效载荷(没有最终\r\n
)它给出1828字节长度;通过添加\r\n
,计数长度为1830字节。在这两种情况下,它似乎都与content-length
标题中声明的长度不同。
HTTP/1.1 200 OK
X-Powered-By: Express
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: HEAD, POST, GET, OPTIONS, DELETE
Access-Control-Allow-Headers: origin, content-type, X-Auth-Token, Tenant-ID, Authorization
server: Apache-Coyote/1.1
set-cookie: hadoop.auth="u=frb&p=frb&t=simple&e=1453410695487&s=YUl/hzzvVQ27/n4yeyi8ZL3r7K8="; Version=1; Path=/; Expires=Thu, 21-Jan-2016 21:11:35 GMT; HttpOnly
Content-Type: application/json; charset=utf-8
transfer-encoding: chunked
date: Thu, 21 Jan 2016 11:11:35 GMT
connection: close
Content-Length: 1829
ETag: W/"725-zwbM26xiKZvcP52NTX57Pg"
725
{"FileStatuses":{"FileStatus":[{"pathSuffix":".Trash","type":"DIRECTORY","length":0,"owner":"frb","group":"frb","permission":"700","accessTime":0,"modificationTime":1437696000073,"blockSize":0,"replication":0},{"pathSuffix":"def_serv","type":"DIRECTORY","length":0,"owner":"frb","group":"frb","permission":"755","accessTime":0,"modificationTime":1453133134503,"blockSize":0,"replication":0},{"pathSuffix":"hivetest","type":"DIRECTORY","length":0,"owner":"frb","group":"frb","permission":"755","accessTime":0,"modificationTime":1437667486016,"blockSize":0,"replication":0},{"pathSuffix":"mrtest","type":"DIRECTORY","length":0,"owner":"frb","group":"frb","permission":"755","accessTime":0,"modificationTime":1437647900960,"blockSize":0,"replication":0},{"pathSuffix":"mrtestoutput","type":"DIRECTORY","length":0,"owner":"frb","group":"frb","permission":"755","accessTime":0,"modificationTime":1437672805148,"blockSize":0,"replication":0},{"pathSuffix":"prueba1","type":"DIRECTORY","length":0,"owner":"frb","group":"frb","permission":"755","accessTime":0,"modificationTime":1453374021476,"blockSize":0,"replication":0},{"pathSuffix":"serv1","type":"DIRECTORY","length":0,"owner":"frb","group":"frb","permission":"755","accessTime":0,"modificationTime":1453301564320,"blockSize":0,"replication":0},{"pathSuffix":"test","type":"DIRECTORY","length":0,"owner":"frb","group":"frb","permission":"755","accessTime":0,"modificationTime":1453301887369,"blockSize":0,"replication":0},{"pathSuffix":"test2","type":"DIRECTORY","length":0,"owner":"frb","group":"frb","permission":"755","accessTime":0,"modificationTime":1453369175937,"blockSize":0,"replication":0},{"pathSuffix":"vaya","type":"DIRECTORY","length":0,"owner":"frb","group":"frb","permission":"755","accessTime":0,"modificationTime":1453369690198,"blockSize":0,"replication":0}]}}
0
编辑3
我尝试过另一台客户端机器......它有效!在这种情况下,服务器继续发送content-lenght
和transfer-encoding=chunked
,但curl
认为没有,并且没有发送RESET。 curl
版本不同:
$ curl --version
curl 7.43.0 (x86_64-apple-darwin14.0) libcurl/7.43.0 SecureTransport zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz UnixSockets