ietf-nntp Re: LIST HEADERS inconsistency issue

[Russ Allbery]

Jeffrey M Vinocur <jeff at litech.org> writes:
> On Wed, 8 Oct 2003, Russ Allbery wrote:

>> In other words, say that HDR must reject the command unless information
>> about that header (its value or its nonexistence) is available for all
>> articles in the specified range.

> So you check that before sending the response code...but what if some of
> the information becomes unavailable during the time in which the
> response is being sent?

> (Not that this is necessarily the only place where this sort of
> concurrency might be a problem, but I'm wary of having the protocol
> specification force complexity of implementation.)

Well, the underlying idea is that if you're serving HDR out of a database,
the database needs to be consistent and you shouldn't return data until
your database is complete for the articles in question.  So I'm not sure
where this situation would arise; it would have to be in a case where the
administrator is changing the set of headers that go into HDR while the
HDR command is running... and even then, it would only affect new incoming
messages and I'd think that the HDR command would establish its range
first.

The goal is to encourage people to have a completely consistent database
(either a header is in it or a header isn't) for the whole spool where
possible, and if that isn't possible, to not return results about that
header unless it's at least consistent across the articles in question.

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