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