Re: Changi: Problems retrieving group list
Jonathan de Boyne Pollard
>>>>
>>>> I'm experiencing problems with some news readers and Changi, e.g.,
>>>> Pan for Linux. Retrieving the list of news groups does not work for
>>>> news.ecomstation.nl and a private news server I frequently use. The
>>>> client just sits there forever. The clients are said to comply with
>>>> the GNKSA.
>>>>
>>> As far as I'm aware, Changi has no problems with the newsgroup list.
>>> You need a packet trace to see what you're getting back from the
>>> server and see if the last line with a single dot character is
>>> somehow corrupted or missing.
>>>
>> I can see that the reader issues a "LIST NEWSGROUPS" command. Changi
>> answers with "No list of newsgroup descriptions available." So it
>> probably might work if the reader only issued a "LIST" command?
>>
> Yes, sounds to me like the client is issuing the wrong command, but
> even if it is, it should return no groups rather than "sitting there
> forever".
>
It sounds as if Pan is badly written, is issuing LIST NEWSGROUPS without
checking the server capabilities for the LIST capability beforehand, and
is expecting LIST NEWSGROUPS to never result in anything other than a
2xx status code. It wouldn't be the first reader to deviate from the
protocol by not checking status codes with optional commands. And this
is one of the common results of getting the protocol wrong: the client
waiting for a multi-line response that the server has stated it isn't
sending.
It's worth noting that Changi doesn't implement CAPABILITIES, so Pan
really has no business thinking that Changi supports anything more than
the RFC977 protocol, which only includes plain unadorned LIST. As
RFC2980 §2.1.6 makes clear, 503 is most definitely a status that NNTP
clients should expect to see from LIST NEWSGROUPS.
> On Changi the "newsgroups" file contains the newsgroup descriptions
> and is not updated when you add or remove groups from the server.
> Usually it doesn't exist at all IME as nobody seems to be bothered
> about the descriptions.
>
The reported response indicates to me that Changi at least knows how to
respond to the command. (I'd expect a "command not implemented"
response to say something more along those lines.) So one question is
why it's not finding and using the contents of that file.
Jonathan de Boyne Pollard
It sounds as if Pan is badly written, is issuing LIST NEWSGROUPS without checking the server capabilities for the LIST capability beforehand, and is expecting LIST NEWSGROUPS to never result in anything other than a 2xx status code. It wouldn't be the first reader to deviate from the protocol by not checking status codes with optional commands. And this is one of the common results of getting the protocol wrong: the client waiting for a multi-line response that the server has stated it isn't sending.
Hah! A little bit of research shows this indeed to be the case.
Pan is broken. There was a thread about this very bug on the Pan-users
mailing list in July 2008, where Per Hedeland came up with a patch to
Pan's broken response code parser. It became Pan bug #545220.
John F. Morse
microsoft.public.internet.news.reader.software were removed -- but then
reentered since I don't know where you lurk.]
[Followups set to news.software.nntp, news.software.readers.]
You trimmed off the attributes, so I have no idea to whom the following
is directed. With that in mind, "To whom it may concern" and "caveat
emptor":
Pan is an old newsreader. It is still a good one, but you need to
realize there are new RFCs, and protocols (status codes, etc.) have
changed since Pan was written.
Furthermore, the "good" Pan is version 0.14.2.91 (August 31, 2003) and
not the more current beta version 0.133 (Aug 1, 2008). There was no
mention above of the version used.
The GNKSA is also very old ("Last modification: Jul 27 2002").
--
John
When a person has -- whether they knew it or not -- already rejected the Truth, by what means do they discern a lie?
Jonathan de Boyne Pollard
>>
>> It's worth noting that Changi doesn't implement CAPABILITIES, so Pan
>> really has no business thinking that Changi supports anything more
>> than the RFC977 protocol, which only includes plain unadorned LIST.
>> As RFC2980 §2.1.6 makes clear, 503 is most definitely a status that
>> NNTP clients should expect to see from LIST NEWSGROUPS.
>>
>>
> Pan is an old newsreader. It is still a good one, but you need to
> realize there are new RFCs, and protocols (status codes, etc.) have
> changed since Pan was written.
>
and not the "new" ones, it would not be using LIST NEWSGROUPS, an
extension to NNTP described in a "new RFC", instead of the "old" RFC977
plain unadorned LIST. Pan's using an NNTP extension that isn't in
RFC977. But it isn't doing what RFC3977 says to do, which is check the
availability of the extension with the CAPABILITIES command first.
Neither is it doing what RFC2980 implies should be done, which is use
the verb but correctly handle the case where the server doesn't actually
implement it, by correctly handling the server replying negatively to
the command (in this particular case with a 503 result code).
> Furthermore, the "good" Pan is version 0.14.2.91 (August 31, 2003) and
> not the more current beta version 0.133 (Aug 1, 2008). There was no
> mention above of the version used.
>
The "good" Pan in this case will be the one with Per Hedeland's
aforementioned July 2008 bugfix in it.
John F. Morse
>>> really has no business thinking that Changi supports anything more
>>> than the RFC977 protocol, which only includes plain unadorned LIST.
>>> As RFC2980 �2.1.6 makes clear, 503 is most definitely a status that
>>> NNTP clients should expect to see from LIST NEWSGROUPS.
>>>
>>> [...]
>>>
>> Pan is an old newsreader. It is still a good one, but you need to
>> realize there are new RFCs, and protocols (status codes, etc.) have
>> changed since Pan was written.
>>
> That doesn't work as an excuse.
I was not offering an "excuse."
> If Pan were adhering to the "old RFCs" and not the "new" ones, it
> would not be using LIST NEWSGROUPS, an extension to NNTP described in
> a "new RFC", instead of the "old" RFC977 plain unadorned LIST. Pan's
> using an NNTP extension that isn't in RFC977. But it isn't doing what
> RFC3977 says to do, which is check the availability of the extension
> with the CAPABILITIES command first. Neither is it doing what RFC2980
> implies should be done, which is use the verb but correctly handle the
> case where the server doesn't actually implement it, by correctly
> handling the server replying negatively to the command (in this
> particular case with a 503 result code).
When did I say Pan was written?
When was CAPABILITIES added to RFC 3977?
http://tools.ietf.org/html/rfc3977#section-5.2
Your cart appears to be in front of your horse.
>> Furthermore, the "good" Pan is version 0.14.2.91 (August 31, 2003)
>> and not the more current beta version 0.133 (Aug 1, 2008). There was
>> no mention above of the version used.
>>
> The "good" Pan in this case will be the one with Per Hedeland's
> aforementioned July 2008 bugfix in it.
That would depend on which Pan his patch is applied. ;-)
I don't have the message and don't know who Per Hedeland is. You must
have added the unneeded crossposting after his message.
Julien ÉLIE
> The reported response indicates to me that Changi at least knows how to respond to
> the command. (I'd expect a "command not implemented" response to say something
> more along those lines.) So one question is why it's not finding and using the
> contents of that file.
Probably because the file does not exist on the news server.
For instance, INN answers 503 when <pathetc>/newsgroups does not exist
or is not readable by the news user. It would be the same for
other files like active.times, distributions, distrib.pats, moderators,
motd.news (for LIST MOTD) or subscriptions.
When the file exists, but is empty, we have 215 followed by an empty
multi-line block (thus directly the final dot ".").
--
Julien ÉLIE
« La médecine est un métier dangereux. Ceux qui ne meurent pas
peuvent vous faire un procès. » (Coluche)
Jonathan de Boyne Pollard
That doesn't work as an excuse. If Pan were adhering to the "old RFCs" and not the "new" ones, it would not be using LIST NEWSGROUPS, an extension to NNTP described in a "new RFC", instead of the "old" RFC977 plain unadorned LIST. Pan's using an NNTP extension that isn't in RFC977. But it isn't doing what RFC3977 says to do, which is check the availability of the extension with the CAPABILITIES command first. Neither is it doing what RFC2980 implies should be done, which is use the verb but correctly handle the case where the server doesn't actually implement it, by correctly handling the server replying negatively to the command (in this particular case with a 503 result code).
When did I say Pan was written? When was CAPABILITIES added to RFC 3977? Your cart appears to be in front of your horse.
No. The excuse that you gave doesn't work, as I said. Think! If
Pan really were written to pre-date all of these things, as
you claimed, then it wouldn't be using a later NNTP extension
instead of the original RFC977 command. And the simple fact
is that it didn't properly account for the fact that the extension
might yield a negative response — something that RFC2980 explicitly
lists as a possibility.
Furthermore, the "good" Pan is version 0.14.2.91 (August 31, 2003) and not the more current beta version 0.133 (Aug 1, 2008). There was no mention above of the version used.
The "good" Pan in this case will be the one with Per Hedeland's aforementioned July 2008 bugfix in it.
I don't have the message and don't know who Per Hedeland is. You must have added the unneeded crossposting after his message.
That's because you haven't read this thread properly. Read all of the messages.