CORRECT PATCH Re: sync_client bails when encountering a deleted message

[Ken Murchison]

John Capo wrote:
> Quoting Ken Murchison (murch at andrew.cmu.edu):
>> John Capo wrote:
>>> Quoting John Capo (jc at irbs.com):
>>>> Quoting Ken Murchison (murch at andrew.cmu.edu):
>>>>> I don't think I was clear.  With my proposal, we're well past "UPDATE".  
>>>>> I'm talking about cutting the command short after "(<flags>)".  No 
>>>>> header_size or anything after.
>>>> I guess I don't understand what you mean.
>>>>
>>>> It sure looks to me like cmd_upload() has to detect that the header
>>>> size it is waiting for will not arrive and recover gracefully rather
>>>> than sending a BAD that the client sees as the response for its
>>>> next command.  Patch attached.
>>> The server needs to push the character back except on EOF, grrrr.
>> Here's what I was thinking.  We might be able to bump the cache flush 
>> down to parse_err, but I'm not sure if this is correct/suboptimal for 
>> SIMPLE.
> 
> Ths might work if you add an eatline() in the client before returning.
> The BAD response from the server must be discarded somehow or the
> BAD response will be seen by the client as the response to the next
> client command.  It seems to me that no response is needed since
> the client is not expecting one.

Hmm.  You're right.  I don't like that.  The client should expect and 
process a response whether it sends the full upload command, or it 
aborts the upload (just like SASL allows a cancel by the client).  I'm 
going to work on this some more to clean it up.

I'm not too concerned with other syntax errors, there shouldn't be any 
since we control the client code.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University