From: John Capo (no email)
Date: Tue May 15 2007 - 15:34:08 EDT
Quoting Ken Murchison ():
> John Capo wrote:
> >Quoting Ken Murchison ():
> >>Ken Murchison wrote:
> >>>Obviously, the chances of header_size being 0xdeadbeef is remote, but it
> >>>is possible. Would it make more sense to use ULONG_MAX as the "failure
> >>>size"?
> >>Or better yet, how about just using 0 (zero)? IIRC, RFC2822 stipulates
> >>that the message header has to be non-zero (Date and From are mandatory)
> >
> >I have seen zero size messages created with IMAP uploads from desktop
> >clients. This is probably a bug elsewhere. I do not know if the
> >zero size messages were replicated.
> >
> >Sending more than one magic number would be the safest way. The
> >value of the second magic number could be used to signal other
> >conditions if needed. I can't imagine what that would be other
> >than aborting the upload. Two ULONG_MAX is a row can't be a valid
> >message.
>
> After thinking about this some more,do we even need a magic number? If
> we don't send anything after the flags list, shouldn't this be enough to
> signal that we have an invalid/missing message?
We still need to see what's next in the stream if anything. When
upload_message_work() returns due to not being able to open a
message, the next byte in the stream should be the first letter of
a command. Testing the next character returned by prot_getc() for
alpha or numeric could signal an abort. If its alpha then its the
next command. If its numeric then its the header size. prot_ungetc()
the character and return or fetch the header size from the stream
and continue.
If the connection is closed prot_getc() would return EOF and
cmd_upload() would return to cmd_loop(). cmd_loop() would also see
EOF since its a flag in the prot structure. Not sure how to test
the EOF case.
I'll see if the basic idea works later today.
John Capo
>
> --
> Kenneth Murchison
> Systems Programmer
> Project Cyrus Developer/Maintainer
> Carnegie Mellon University
|
|
|