Dear news.software.nntp,

As per my previous thread, I've started experimenting with NNTP.

I first set up INN in a VM that I'm "talking to" for the moment.

So testing things that work is easy. What I'm more concerned with,
right now, is the negative testing: testing the things that shouldn't
work. [Something that most programmers forget to do.]

So, I can trivially create /an NNTP server/ that replies with the wrong greeting line, or perhaps no line at all.

What I'm wondering about, is how the software should behave if the first
line is simply invalid. There are various cases, such as

1) the initial greeting never arrives,

2) the initial response code is not one of 200, 201, 400, 502,

3) the initial response line does not terminate with CR LF within
512 octets,

4) the byte following the response code is not space.

Reading RFC 3977, section 3.1, I can get the sense that

201This is a valid response line CR LF

but nobody does it in practice? [Note, the CR LF is meant without
space separation in my example.] Spec lawyers would be helpful here,
maybe.

It's easy to create these examples, and then have an NNTP library return
or throw an error (yes, even in C; we just use longjmp()), but how would
end user software want to deal with such cases?

How do people using newsreaders want to log such errors, and/or complain
about it? To whom?

Having some answers to these questions may help me determine how I
structure my library, and create a newsreader.

Thanks,
--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | twitter: @myrkraverk

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-09-27, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:

So testing things that work is easy. What I'm more concerned with,
right now, is the negative testing: testing the things that shouldn't
work. [Something that most programmers forget to do.]

So, I can trivially create /an NNTP server/ that replies with the wrong greeting line, or perhaps no line at all.

Throw an error. The Robustness Principle is wrong. Do not be "liberal
in what you accept" - that way lies madness.

Reading RFC 3977, section 3.1, I can get the sense that

201This is a valid response line CR LF

No. Section 3.2: Arguments MUST be separated from the numeric status
indicator and from each other by a single space."

It's easy to create these examples, and then have an NNTP library return
or throw an error (yes, even in C; we just use longjmp()), but how would
end user software want to deal with such cases?

How do people using newsreaders want to log such errors, and/or complain about it? To whom?

My personal recommendation is to show a human-friendly error whenever
you can, but there absolutely must be a way for the user to press a
button or something to see the raw network data (and bear in mind the possibility of binary data) so that they can give helpful diagnostic information to the server operator if necessary.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:

It's easy to create these examples, and then have an NNTP library return
or throw an error (yes, even in C; we just use longjmp()), but how would
end user software want to deal with such cases?

It’s more than 20 years since I last had to integrate a C library which reported errors via longjmp() and I’m still bitter about it. As a matter
of API design, I’d rather C library communicated errors via return
values (and pointer parameters, where more complex error information is required).

I’m not 100% convinced that a general-purpose NNTP library is a very
useful thing. NNTP just isn’t really the hard bit. (NNTP-related functionality would no doubt be a distinct module within a newsreader,
but with an API friendly to how the rest of the newsreader worked.)

How do people using newsreaders want to log such errors, and/or complain about it? To whom?

If the news server is just plain broken then a single error message in
the UI would seem appropriate.

--
https://www.greenend.org.uk/rjk/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

For your reference, records indicate that
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:

What I'm wondering about, is how the software should behave if the first
line is simply invalid.

It is entirely up to you how to architect your software. How you do or don’t abstract away lower levels is always a matter of trade-offs, and they may
have a significant impact on how you provide functionality at a higher level.

For example, if you want to provide an “offline” mode, something somewhere inside your code needs to make the determination of what can be done in that mode. And that includes what happens if you fail to go “online” for *whatever* reason. It’s not such a problem these days with broadband like it was back in the days of dialup, but it *is* somewhat related to command pipelining, too, so keep that in mind as you make your decisions.

For my framework, I made the decision to have different objects for the
server and the session/connection to that server. The groups and article objects deal with only servers, and it is up to the servers to manage their connection(s).

Reading RFC 3977, section 3.1, I can get the sense that

201This is a valid response line CR LF

but nobody does it in practice?

As Jon said, that’s not strictly valid, but my parser would certainly accept it, because I’m looking for any integer (not just a 3 digit one) and then skipping any amount of whitespace (including none). I obviously disagree
with Jon, and I intentionally tried to be more permissive than the standard
to future-proof my code to some degree. If you want to write a validating framework, you’re welcome to do so; I just wanted a functional one.

It's easy to create these examples, and then have an NNTP library return
or throw an error (yes, even in C; we just use longjmp()), but how would
end user software want to deal with such cases?

At some level, they just don’t care about any of that. They just want to know what new messages there are, or they just want to post a reply. If it comes back as “0 new messages” or “saved to outgoing messages”, that might
be a big deal, and it might not be. In my book, not every transient
network error deserves a be a red alert.

How do people using newsreaders want to log such errors, and/or complain about it? To whom?

Different people will care to different degrees. You’ll never be able to please all the people all the time. Generally, people want software that *works*, not error logs that tell them in exquisite detail why it doesn’t.

--
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)