#45 no headers at all after group update (error parsing xover)

[Fathi Boudra]

This is a forwarded bug :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364117

-forwarded message-------------------------------
When refreshing groups the headers apparently get
downloaded,
but afterwards all groups are supposedly empty. klibido
prints
an error message like the following for every message:

Error parsing xover: 1294353
Blue Sonnet 05 (final) - (DivX 5/j dub/e hsub) - (HD) -
(25/38) - yEnc - "Blue Sonnet - 05 [HD].avi.023" (16/20)
nomail@bell-chan.invalid (Bell-chan)
13 Mar 2006 16:55:43 GMT
<4415a3e7$0$25440$ed362ca5@nr1.newsreader.com>
542000 4164

(line breaks are mine)

The news server in question is NewsPlex 4.4 / Linux on
the same LAN.

Note that I'm using a GNOME desktop, I only have of KDE
what k3b and klibido pulled in.
-------------------------------------------------

cheers,

Fathi

[Fathi Boudra]

Logged In: YES
user_id=1122924

Submitter fixed the bug :
> A recompile of klibido with the field number checks
> relaxed in header.cpp (from !=9 to <9) fixes my problem.

Please, can you check the changes. If it's ok, we can
include them in debian package 0.2.5-3 or wait for next
release inclusion.

[Fathi Boudra]

Logged In: YES
user_id=1122924

Submitter fixed the bug :
> A recompile of klibido with the field number checks
> relaxed in header.cpp (from !=9 to <9) fixes my problem.

Please, can you check the changes. If it's ok, we can
include them in debian package 0.2.5-3 or wait for next
release inclusion.

[Alessandro Bonometti]

Logged In: YES
user_id=523378

It seems your server sends a different number of fields
thant what it's common...
It's probably a KLibido bug because I assume that there
are 9 fields in the "xover" line, whereas this number can
vary and should be deduced from the "list overview.fmt"
line...
Please, can you:
- Telnet to the news server on port 119
- authenticate if necessary with authinfo user <username>,
authinfo pass <password>
- give the command "list overview.fmt"
- Send me the output of this command...
Thanks.

[Fathi Boudra]

Logged In: YES
user_id=1122924

> It seems your server sends a different number of fields
> thant what it's common...

That's true, it sends 10 fields with the last two empty,
instead of 9 with the last empty.

> It's probably a KLibido bug because I assume that there
> are 9 fields in the "xover" line, whereas this number can
> vary and should be deduced from the "list overview.fmt"
> line...

True, but newsplex's LIST OVERVIEW.FMT is wrong anyway:

200 NewsPlex 4.4 (posting allowed)
215 Order of fields in overview database.
Subject:
From:
Date:
Message-ID:
References:
Bytes:
Lines:
.
205 bye

That indicates only 9 fields (article number and one empty
field at the end are implicit).

I talked this over with Adam Mirowski (newsplex's upstream)
and he said:

> I see... Newsplex has been doing this for 7 years now. I
don't even remember why.
> I guess I saw various servers doing this. [...] I don't
think the RFC prevents from
> adding extra tabs. They will be empty fields of
unspecified meaning. Newsplex just
> ignores such extra fields on input.
> I guess I could suppress them. But in any case, a news
reader should tolerate such
> minor inconsistencies.

So klibido is buggy, because it should read LIST
OVERVIEW.FMT, and
newsplex is buggy because it should fix its LIST
OVERVIEW.FMT output and/or send just 9 fields.

Anyway, I can see Adam's point - if no other newsreader has
complained in the past (they don't, I tried a lot myself),
then klibido's XOVER parsing should probably be relaxed a bit.

Maybe klibido could:

1) require at least 9 fields (that's the minimum per RFC)
2) optionally read LIST OVERVIEW.FMT and require all fields
declared there to actually exist
3) ignore any extra fields, since one can't be sure what the
contents are anyway.

1) + 3) includes 2) , if you don't plan to make use of
common optional
fields in klibido.

Regards,

Christian

[Fathi Boudra]

Logged In: YES
user_id=1122924

> > It seems your server sends a different number of fields
thant what it's
> > common...

That's true, it sends 10 fields with the last two empty,
instead of 9
with the last empty.

> > It's probably a KLibido bug because I assume that there
are 9 fields in the
> > "xover" line, whereas this number can vary and should be
deduced from the
> > "list overview.fmt" line...

True, but newsplex's LIST OVERVIEW.FMT is wrong anyway:

200 NewsPlex 4.4 (posting allowed)
215 Order of fields in overview database.
Subject:
From:
Date:
Message-ID:
References:
Bytes:
Lines:
.
205 bye

That indicates only 9 fields (article number and one empty
field at
the end are implicit).

I talked this over with Adam Mirowski (newsplex's upstream)
and he said:

> I see... Newsplex has been doing this for 7 years now. I
don't even remember why.
> I guess I saw various servers doing this. [...] I don't
think the RFC prevents from
> adding extra tabs. They will be empty fields of
unspecified meaning. Newsplex just
> ignores such extra fields on input.
> I guess I could suppress them. But in any case, a news
reader should tolerate such
> minor inconsistencies.

So klibido is buggy, because it should read LIST
OVERVIEW.FMT, and
newsplex is buggy because it should fix its LIST
OVERVIEW.FMT output
and/or send just 9 fields.

Anyway, I can see Adam's point - if no other newsreader has
complained
in the past (they don't, I tried a lot myself), then
klibido's XOVER
parsing should probably be relaxed a bit.

Maybe klibido could:

1) require at least 9 fields (that's the minimum per RFC)
2) optionally read LIST OVERVIEW.FMT and require all fields
declared
there to actually exist
3) ignore any extra fields, since one can't be sure what the
contents
are anyway.

1) + 3) includes 2) , if you don't plan to make use of
common optional
fields in klibido.

Regards,

C.