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

open
nobody
None
5
2006-04-22
2006-04-22
Fathi Boudra
No

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

Discussion

  • Fathi Boudra
    Fathi Boudra
    2006-04-24

    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
    Fathi Boudra
    2006-04-24

    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.

     
  • 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
    Fathi Boudra
    2006-05-22

    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
    Fathi Boudra
    2006-05-22

    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.