ietf-nntp Concerning Streaming
greg andruk
gja at meowing.net
Tue Jan 1 16:15:19 PST 2002
On Tue, Jan 01, 2002 at 10:27:02PM +0000, Clive D.W. Feather wrote:
> I don't understand why people want POST to be not streamable.
It's not a matter of wants, but of recognizing existing implementations =(
[...]
> [C] Test text
> [C] .
> [C] DATE
> [S] 240 posting accepted
> [C] GROUP misc.test
>
> can the client rely on receiving a 111 line next, or is it possible that
> the server threw away the DATE command, so that the next response will be
> the 211 ?
Yes, it's possible. NNTP 1.5.x forks and execs inews on each POST.
If batching is not copmiled in, it does the same with rnews on IHAVE.
> If a server is likely to do something that might upset stdio buffering as
> part of processing a POST, then it needs to be non-streamable. Is this
> likely ?
Yes, there are still sites running the 1.5.x code.
> I seem to recall there was a belief that LIST EXTENSIONS might kick in a
> new invocation of the server with extra modules loaded. Hence the desire to
> make it non-streamable.
I can see where the available extensions could easily differ before and
after, say, a MODE command, but for the LIST itself to be cause for a new
process seems odd. Was that idea maybe be a holdover from the old proposal
to change AUTHINFO's return codes from x8x to x5x if a LIST EXTENSIONS was
seen? I thought that those magical properties went away with the
redefinition of x8x codes from local to auth.
More information about the ietf-nntp
mailing list