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

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.

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/

Richard Kettlewell wrote:

> 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.

I have never encountered a library which does that. Which library was
that?

> 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).

Personally, i think that, at least for a library, an error should _only_
be communicated by return value. If more complex information is required,
then the return value can be made more complex. I don't think i've ever
used a library that communicates information via a pointer parameter.

One thing i've experienced in multiple libraries is a system a bit like
what errno.h offers, but done via a pair of subroutines that retrieve and
assign to some hidden global variable. I don't like this for the same
reason i don't like subroutines that use errno (unless they're syscall
wrappers), but in at least two of the cases the library has also come with
a way to set a callback subroutine to automatically deal with errors
instead. This is nice, since it means that the code doesn't get all
obfuscated with error checking after every subroutine call, but it's
annoying that each library needs to come with its own unique subroutine
for this, and i do worry about it being overly general in treating all
errors lethally.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr. bluemanedhawk.github.io
Warning: Low flying owls. Lost chihuahua.

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

Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
> Richard Kettlewell wrote:
>> 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.
>
> I have never encountered a library which does that. Which library was
> that?

libpng

>> 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).
>
> Personally, i think that, at least for a library, an error should
> _only_ be communicated by return value. If more complex information
> is required, then the return value can be made more complex. I don't
> think i've ever used a library that communicates information via a
> pointer parameter.

Return value plus a pointer to additional information can certainly be
transformed into a struct containing both, though there’s an impact on
source code verbosity, object code size and performance.

For example if the extra information goes up to, say, 64 bytes, putting
it in a return value commits you to a 64-byte copy on every
return. However if it’s a pointer parameter, you only need to fill in
the fields relevant to the error that actually happened. In the happy
path, where there’s no error, that’s none of them.

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