[NNTP] draft-ietf-nntpext-streaming-02

Andrew - Supernews andrew at supernews.net
Wed Oct 13 17:14:01 PDT 2004


>>>>> "Russ" == Russ Allbery <rra at stanford.edu> writes:

 >> However, the idea of returning a deferral in response to TAKETHIS
 >> (or indeed as the final response after IHAVE) is in any event
 >> logically somewhat flawed. The client in this case will always
 >> have sent the entire article body, and it is not reasonable to
 >> expect a client to do that repeatedly. Once the body is
 >> transferred once, the server has all the information needed to
 >> decide whether to accept or reject the article; transient errors
 >> at this point, such as "disk full", are better handled by pausing
 >> or throttling the server (without sending either 239 or 439 to the
 >> client). Some implementations do actually return 431 in that case,
 >> but practical experience is that the resulting behaviour is never
 >> good (some senders will discard the articles, others will retry
 >> them indefinitely, potentially wasting large bandwidth volumes;
 >> throttling the server works much better).

 Russ> So from a protocol standpoint, you believe the situations under
 Russ> which a server might return a deferral to TAKETHIS or IHAVE are
 Russ> better handled by just closing the connection without a
 Russ> response instead?

The distinguishing factor is whether the server has any reason to
expect that an immediate following TAKETHIS for a different article,
or a later following TAKETHIS for the same article, has any chance of
success. If the server is getting errors (such as disk full) that
aren't article-specific, then it should really fail in a way that also
isn't article-specific (and closing the connection, possibly rejecting
further connections until the problem is resolved, seems the better
option).

Such an unsolicited close of the connection should probably be done
with a 400 response rather than silently (see the base draft).
(Existing streaming clients do seem to understand this, as existing
server implementations do this when shutting down connections when
throttled)

Maybe someone can come up with a specific circumstance where returning
a deferral would make sense, but so far I've been unable to think of
one (and none of my own implementations have ever done it). If it
stays in the draft, then (a) it specifically needs to be the 431 code
rather than a new one, and (b) it should be made clear that it's only
appropriate if the problem is a _transient_ problem affecting _only that
specific article_, and that more general failures should be handled by
a connection close.

-- 
Andrew, Supernews
http://www.supernews.com




More information about the ietf-nntp mailing list