> It seems like 'noreply' is not the only command that is not immune to > syntax errors. Recently the following test was added: > > # cas empty > print $sock "cas foo 0 0 6 \r\nbarva2\r\n"; > is(scalar <$sock>, "ERROR\r\n", "cas empty, throw error"); > > But see what's happens: > > - server reads "cas foo 0 0 6 \r\n". Wrong number of tokens (CAS > value missing), server can't parse command reliably, sends ERROR. > > - server reads "barva2\r\n"! No such command, server sends another > ERROR (and you can imagine what would happen if this data would by > accident be "flush_all\r\n", for instance). > > It's the same transparent proxy problem. Can't parse -> can't > reliably swallow the command. Should we made close-on-error behaviour > mandatory for parse errors? This is reasonable, since it's very > unlikely that any client out there has logic to recover from self > malformed commands.
So... In production you're probably not likely to hit that too often. It's more about errors that are sent after parsing. Those I think are a crux in the noreply more than issues with wrong number of tokens. On the other hand, making a change like that might adversely affect someone with a slighty, but not entirey, broken configuration. Say they do something braindead like occasionally send a bad command in the middle of some library, but the rest of their code is right. Could be jarring, hard to track down. I'd take a patch as a compiletime option! close_on_parse_error. It'd be helpful for those of us writing clients or developing new code against memcached. -Dormando
