2

I'm trying the following one:

$ 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

At first stage, I though this was a problem with the server, but sniffing the traffic on the remote side I found the reset was sent by curl! Why?

enter image description here

Some useful information:

$ 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

Any idea about what is happening? Thanks in advance!

EDIT 1

As suggested by @nos, I'm including the detail about the content-length header and the actual payload length sent:

enter image description here

Interesting, it seems there is something incorrect there...

EDIT 2

Printing the whole Http response. The first chunk is delared to be 1829 bytes length (725 hexadecimal), but counting the payload (without the final \r\n) it gives 1828 bytes length; by adding \r\n the count is 1830 bytes length. In both cases it seems it differs from the declared length in the content-length header.

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

EDIT 3

I've tried with another client machine... and it works! In this case, the server continues sending both content-lenght and transfer-encoding=chunked, but it is considered OK by curl and no RESET is sent back. curl version is different:

$ 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

enter image description here

enter image description here

frb
  • 3,738
  • 2
  • 21
  • 51
  • Did the server send the complete response before the FIN packet is sent ? You'll need to verify this by looking at the Content-Length header in the response compared to how many bytes there actually are in the content. – nos Jan 21 '16 at 12:08
  • Thanks for your time. Please, see my edit, I've added the detail about the `content-length` header. It seems there is something incorrect there... I've found [this](http://stackoverflow.com/questions/3304126/chunked-encoding-and-content-length-header) other related SOF question, but do not know if that's the reason the client (`curl`) is sending the reset. – frb Jan 21 '16 at 13:09
  • `content-length : 1829\r\n`? Hmm, I see other `\r\n`s listed too. Are you running this on Windows? – shellter Jan 21 '16 at 14:43
  • Both client and server are running in CentOS machines. – frb Jan 21 '16 at 14:48
  • 2
    @shellter: HTTP uses `\r\n` line separators for header fields. That's correct here. – DarkDust Jan 21 '16 at 17:05
  • @DarkDust : Thanks for the info, I'll try to file that away for future reference ;-) ! Good luck to all. – shellter Jan 21 '16 at 17:06
  • 2
    @frb Did you count that the http body actually has 1829 bytes ? curl is giving you an error either because the body has less bytes than that before the server closes the connection, or because the response contains a content-length header but also uses chunked encoding in the response body, and that combination is something you are not supposed to do according to the http protocol (which is what wireshark is also telling you) – nos Jan 21 '16 at 17:56
  • @nos, please, see my second edit. The first chunk is declared to be 1829 bytes length (725 hexadecimal), but counting the payload (without the final `\r\n`) it gives 1828 bytes length; by adding `\r\n` the count is 1830 bytes length. In both cases it seems it differs from the declared length in the `content-length` header. Anyway, should not be discarded the `content-length` is the transfer encoding is `chunked`? ([reference](https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4)) – frb Jan 22 '16 at 06:39
  • @frb Yes, the Content-Length header should not be there when the content is chunked, so certainly your server is doing stuff it should not do. – nos Jan 22 '16 at 07:50
  • I've tried with another client machine and... now it works! (please, see my edit 3). I've seen the `curl` version is different (a recent one), so I'm starting to think that modern versions of `curl` relax the checks. – frb Jan 22 '16 at 08:15
  • So @nos, you were totally right, and after fixing the server side it is working like a charm. If you post the answer, I'll be glad to vote for it :) Thanks! – frb Jan 25 '16 at 16:55

0 Answers0