cugblbs / memcached

Automatically exported from code.google.com/p/memcached
0 stars 0 forks source link

Incomplete command does not result in ERROR response #381

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?

1. echo -n "get key" | nc -C localhost 11211

What is the expected output? What do you see instead?

I'd expect the server to reply with "CLIENT_ERROR" or "ERROR", depending on the 
parsing state. However the server currently does not send any reply.

What version of the product are you using? On what operating system?

1.4.20

Original issue reported on code.google.com by tgrab...@cloudius-systems.com on 21 Oct 2014 at 11:39

GoogleCodeExporter commented 9 years ago
memcached ascii protocol will wait indefinitely for a newline at least.

Original comment by dorma...@rydia.net on 30 Nov 2014 at 1:45

GoogleCodeExporter commented 9 years ago
In case the client closes its side the newline cannot obviously arrive. I'd 
expect that an end-of-stream instead of newline could be treated as parsing 
error. Is this case documented somewhere?

When you say that the protocol will wait indefinitely for newline in that case, 
doesn't it mean that the server will keep the connection state which 
effectively leaks it?

Original comment by tgrab...@gmail.com on 30 Nov 2014 at 9:45

GoogleCodeExporter commented 9 years ago
end of stream will close the connection internally. there's no way for it to 
write an error out at that point, since the connection is now closed.

Original comment by dorma...@rydia.net on 30 Nov 2014 at 10:25

GoogleCodeExporter commented 9 years ago
Is this a limitation which results from the way memcached is implementated?

TCP connections can be closed independently by each side. The client may 
shutdown its side, triggering EOF on the server's input pipe and continue to 
receive data. The server may still send data and decide on its own when it 
closes its side.

Original comment by tgrab...@gmail.com on 1 Dec 2014 at 8:45

GoogleCodeExporter commented 9 years ago
It's not really built to do half-close situations I think... if it detects that 
it just blows out.

That might be the wrong thing to do in some situations I guess. I'll give it 
some more thought. We do have the quit command, and since it's a 
request/response protocol the client is supposed to wait until it receives an 
END before dc'ing. This doesn't work well with echo and netcat but isn't 
generally a problem with real clients.

Original comment by dorma...@rydia.net on 1 Dec 2014 at 9:05