[prev in list] [next in list] [prev in thread] [next in thread] 

List:       imap
Subject:    Re: Correct response when fetching an invalid message
From:       Arnt Gulbrandsen <arnt () gulbrandsen ! priv ! no>
Date:       2003-10-10 8:31:33
[Download RAW message or body]

Slavo Uhrin writes:
> Hello,
> I have a similar question to the previous one about fetching a non 
> existent message sequence.
>
> What exactly should server do when fetching a message with invalid 
> MIME header or body?

This was asked a some time ago. Timo Sirainen answered it well in the 
recent thread about BINARY; look at the archives.

> For example, in case of FETCH ENVELOPE there might be a message in the 
> sequence with a broken e-mail address in one of the required RFC822 
> headers. Parsing of such a message would end up in an error 
> condition. Should the server send an untagged NO response and 
> continue with processing the sequence with the final tagged OK 
> response, or should it stop the processing immediately and issue a 
> tagged NO response?

It should continue processing and complete with NO or BAD.

For example, something like this is good:

C: a fetch 1:3 body[2]
S: * 1 fetch (body[2] {123}
...
)
S: * 2 fetch (body[2] NIL)
S: * 3 fetch (body[2] {4567}
...
)
S: a NO parse error during processing of message 2

IMO, whether or not to send the NIL response depends on the nature of 
the error. I'm a little uncertain about what makes the most sense 
there.

> I think this is not stated by the RFC, so I am asking for a common 
> practice, or a best possible solution.

This is the best practice, because it permits caching clients to work 
well. Each untagged response is parsable, processable and cachable on 
its own, without reference to the command(s) being executed.

--Arnt

[prev in list] [next in list] [prev in thread] [next in thread]