ietf-nntp Requirement for timeout close unclear

Russ Allbery rra at stanford.edu
Thu Jul 5 17:32:38 PDT 2001


greg andruk <gja at meowing.net> writes:
> On Thu, Jul 05, 2001 at 04:25:25PM -0700, Russ Allbery wrote:

>> Hm.  Do we have the same problem that SMTP does, namely that if the
>> post is accepted but the response is lost, the client may assume that
>> it needs to send it again, resulting in duplicates?

> Yes, if the client does not supply its own message ID, or if it isn't
> careful to use the same ID on a repost attempt.  ISTR that early
> versions of Netscape (or maybe it was Mosaic) had big trouble of that
> kind when they lost track of a connection.

>> If so, how do we fix that?

> Encourage or require clients to generate IDs sensibly?

I think we should say something about this in this standard.  I propose:

    The client SHOULD NOT assume that the article has been successfully
    transferred unless it receives an affirmative response from the
    server.  Since, however, the affirmative response may have been sent
    and lost, the client SHOULD use the same message-id in the article
    when resending it or check whether the article was successfully
    posted before resending it to ensure that the resend will not result
    in a duplicate article.

in the section on POST and:

    The client SHOULD NOT assume that the article has been successfully
    transferred unless it receives an affirmative response from the
    server.  A lack of response (such as a dropped network connection or
    a network timeout) SHOULD be treated the same as a 436 error
    response.

in the section on IHAVE.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



More information about the ietf-nntp mailing list