Re: RFC versus sever versus client

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC versus sever versus client

Duncan-42
DLSauers posted on Thu, 10 Nov 2016 02:16:58 +0000 as excerpted:

> I am looking to have a definitive PER *_RFC_* answer that a client
> regardless of SERVER should issue MODE READER, get 500, done, click! Or
> do what one client does, ignore the 500 issue LIST and go on....

I'll punt for the moment on what you're asking for, but never-the-less,
here's my immediate thoughts.

A practical and common RFC guideline and general policy is: Interpret the
RFCs strictly in what you send, but be more tolerant in what you are
prepared to receive.

In this case, that would mean that regardless of whether the RFCs mandate
MODE READER or not, particularly given that there are known servers out
there that don't support it, pan should be prepared to work around
receiving an error for the command, and continue without it the best it
can.

I /was/ going to suggest that a workaround would be using a firewall to
block the 500 error response and replace it with a synthetic response
that looks more like what pan expects.  However, I expect once pan got
that, it would continue making requests as if it were in reader mode, so
it's not as simple as that, as a whole bunch of translation and synthetic
response generation would need to be done.

Which means the only real solution if you're going to use pan with that
server is finding someone who knows enough C++ and is either familiar
enough with the RFCs or willing to /become/ familiar enough with them to
create and submit a patch...

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC versus sever versus client

Per Hedeland
Hi,

Sorry for top-posting, but I'm afraid my normal interleaved-style reply
wouldn't be really useful here...

As a bit of background, NNTP hasn't had much interest from the Internet
standards groups for most of its existence, and thus implementations
have made the extensions they needed when they needed them. It is great
that RFC 3977 exists, but the MODE READER command, introduced by the INN
implementation in 1991 (part of what it needed to achieve its huge
performance improvement over the earlier "reference implementation"),
predates the CAPABILITIES command introduced in 3977 by some 15 years.

And the publication of an RFC obviously doesn't cause support for it to
magically appear in existing implementations, far less in existing
installations of those implementations. Thus there likely exists a large
number of NNTP servers that absolutely require that you use the MODE
READER command if you want reader service, yet will give you a 500 reply
if you try CAPABILITIES.

I think it is reasonable to expect implementors of NNTP servers to have
some knowledge of this background, and not think that RFC 3977 has
everything they need - e.g. RFC 2980 is a good read. It is perhaps
particularly ironic that implementors of a gateway to FidoNet of all
things lack the historical perspecive.:-) And regarding Duncan's mention
of what is known as "Postel's principle", a resonable application of
that is that if you are an NNTP server that only provides reader service,
and a client asks you for reader service, you just say "sure, go ahead"
- while a client ignoring an error response from the server may not be,
since it can lead to all kinds of difficult-to-debug problems down the
line.

Anyway, enough rambling - I think the answer, maybe not to your actual
question but to the question of what needs to be fixed, is perfectly
clear from RFC 3977 - and it is what you could expect from a standard
created by people that actually *have* the historical perspective. It
says:

In section 5.2.2, about the CAPABILITIES command:

   This command MAY be issued at any time; the server MUST NOT require
   it to be issued in order to make use of any capability.

In section 5.3.2, about the MODE READER command:

   If the server is not mode-switching, then the following apply:

   o  If it advertises the READER capability, it MUST return a 200 or
      201 response with the same meaning as for the initial greeting; in
      this case, the command MUST NOT affect the server state in any
      way.

If the implementation of the server in question is done per the letter of
3977, it surely advertises the READER capability, and then per the above
it MUST return a 200 or 201 response to MODE READER, regardless of
whether the CAPABILITIES command has been issued by the client.

--Per Hedeland

On 2016-11-10 13:54, DLSauers wrote:

> On Thu, 10 Nov 2016 03:27:14 +0000, Duncan wrote:
>
>> A practical and common RFC guideline and general policy is: Interpret
>> the RFCs strictly in what you send, but be more tolerant in what you are
>> prepared to receive.
>
> If that is the case, then by that definition, Pan and Knode are the bug
> sources in insisting on MODE READER before doing anything..while other
> clients seem to just ignore, tolerate as you put it, and move on..
>
>  
>> In this case, that would mean that regardless of whether the RFCs
>> mandate MODE READER or not, particularly given that there are known
>> servers out there that don't support it, pan should be prepared to work
>
> What other servers don't support it???? I am curious for reference...
>
> Which also would mean that Pan would not work them since MODE READER is
> the first thing that comes in, and then BOOM, 500, offline.
>
>> around receiving an error for the command, and continue without it the
>> best it can.
>
> Well this is sort of what one other client does...it issues MODE READER,
> gets 500 from this server, then just does LIST anyway...
>  
> Based on this:
>
> https://tools.ietf.org/html/rfc3977#section-3.4.2
>  An implementation MAY, but SHOULD NOT, provide both transit and
>    reader facilities on the same server but require the client to select
>    which it wishes to use.  Such an arrangement is called a
>    "mode-switching" server.
>
> it seems that Pan and Knode which issue this MODE READER get 500, should
> then respond as another client does and just issue LIST
>
> Since this is not a "transit" sever in that Server to server
> communications will occur.. then MODE READER is not correct...????
>
>> I /was/ going to suggest that a workaround would be using a firewall to
>> block the 500 error response and replace it with a synthetic response
>
> My fix, responds to MODE READER, issues 200, Pan then does LIST, and
> every one is happy... I've pulled messages from this server.. Not posted
> with it yet, due to an issue not related to this....
>
>  
>> Which means the only real solution if you're going to use pan with that
>> server is finding someone who knows enough C++ and is either familiar
>> enough with the RFCs or willing to /become/ familiar enough with them to
>> create and submit a patch...
>
> I have a "hackish" fix to it for now... I working on more "proper" fix to
> it after working out how this thing works... since its not my code
> originally.... my original initial fix didn't work because of the way it
> parses commands...
>
> I have a fix... and working on adding some other things...
>
> Based on the RFC's a client *SHOULD*
>
> Connect to SERVER
>
> CAPABILITIES
> parse that for commands
> (optionally switch to Secure mode) based on this, rinse repeat
> CAPABILITIES after switching to secure mode)
> MODE READER if above
> CAPABILITIES
> parse again
> LIST
>
> But the clients I checked with, 3, Pan, Knode, and thunderturkey don't
> issue CAPABILITIES.
>
> Just issue MODE READER and go from there....
>
> So seems that there is a diversion away from the proper route and the
> quick route ....
>
> Doesn't seem to be a complete definitive answer here as it seems all
> servers and clients have gotten away from the RFC's....

_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC versus sever versus client

altbinspam (Bugzilla)
On Thu, 10 Nov 2016 23:12:16 +0100, Per Hedeland wrote:

> Hi,
>
> Sorry for top-posting, but I'm afraid my normal interleaved-style reply
> wouldn't be really useful here...
>
> As a bit of background, NNTP hasn't had much interest from the Internet
> standards groups for most of its existence, and thus implementations
> have made the extensions they needed when they needed them. It is great
> that RFC 3977 exists, but the MODE READER command, introduced by the INN
> implementation in 1991 (part of what it needed to achieve its huge
> performance improvement over the earlier "reference implementation"),
> predates the CAPABILITIES command introduced in 3977 by some 15 years.
>
> And the publication of an RFC obviously doesn't cause support for it to
> magically appear in existing implementations, far less in existing
> installations of those implementations. Thus there likely exists a large
> number of NNTP servers that absolutely require that you use the MODE
> READER command if you want reader service, yet will give you a 500 reply
> if you try CAPABILITIES.
>
> I think it is reasonable to expect implementors of NNTP servers to have
> some knowledge of this background, and not think that RFC 3977 has
> everything they need - e.g. RFC 2980 is a good read. It is perhaps
> particularly ironic that implementors of a gateway to FidoNet of all
> things lack the historical perspecive.:-) And regarding Duncan's mention
> of what is known as "Postel's principle", a resonable application of
> that is that if you are an NNTP server that only provides reader
> service,
> and a client asks you for reader service, you just say "sure, go ahead"
> - while a client ignoring an error response from the server may not be,
> since it can lead to all kinds of difficult-to-debug problems down the
> line.
>
> Anyway, enough rambling - I think the answer, maybe not to your actual
> question but to the question of what needs to be fixed, is perfectly
> clear from RFC 3977 - and it is what you could expect from a standard
> created by people that actually *have* the historical perspective. It
> says:
>
> In section 5.2.2, about the CAPABILITIES command:
>
>    This command MAY be issued at any time; the server MUST NOT require
>    it to be issued in order to make use of any capability.
>
> In section 5.3.2, about the MODE READER command:
>
>    If the server is not mode-switching, then the following apply:
>
>    o  If it advertises the READER capability, it MUST return a 200 or
>       201 response with the same meaning as for the initial greeting; in
>       this case, the command MUST NOT affect the server state in any
>       way.
>
> If the implementation of the server in question is done per the letter
> of 3977, it surely advertises the READER capability, and then per the
> above it MUST return a 200 or 201 response to MODE READER, regardless of
> whether the CAPABILITIES command has been issued by the client.
>
> --Per Hedeland
>
> On 2016-11-10 13:54, DLSauers wrote:
>> On Thu, 10 Nov 2016 03:27:14 +0000, Duncan wrote:
>>
>>> A practical and common RFC guideline and general policy is: Interpret
>>> the RFCs strictly in what you send, but be more tolerant in what you
>>> are prepared to receive.
>>
>> If that is the case, then by that definition, Pan and Knode are the bug
>> sources in insisting on MODE READER before doing anything..while other
>> clients seem to just ignore, tolerate as you put it, and move on..
>>
>>
>>> In this case, that would mean that regardless of whether the RFCs
>>> mandate MODE READER or not, particularly given that there are known
>>> servers out there that don't support it, pan should be prepared to
>>> work
>>
>> What other servers don't support it???? I am curious for reference...
>>
>> Which also would mean that Pan would not work them since MODE READER is
>> the first thing that comes in, and then BOOM, 500, offline.
>>
>>> around receiving an error for the command, and continue without it the
>>> best it can.
>>
>> Well this is sort of what one other client does...it issues MODE
>> READER, gets 500 from this server, then just does LIST anyway...
>>  
>> Based on this:
>>
>> https://tools.ietf.org/html/rfc3977#section-3.4.2
>>  An implementation MAY, but SHOULD NOT, provide both transit and
>>    reader facilities on the same server but require the client to
>>    select which it wishes to use.  Such an arrangement is called a
>>    "mode-switching" server.
>>
>> it seems that Pan and Knode which issue this MODE READER get 500,
>> should then respond as another client does and just issue LIST
>>
>> Since this is not a "transit" sever in that Server to server
>> communications will occur.. then MODE READER is not correct...????
>>
>>> I /was/ going to suggest that a workaround would be using a firewall
>>> to block the 500 error response and replace it with a synthetic
>>> response
>>
>> My fix, responds to MODE READER, issues 200, Pan then does LIST, and
>> every one is happy... I've pulled messages from this server.. Not
>> posted with it yet, due to an issue not related to this....
>>
>>
>>> Which means the only real solution if you're going to use pan with
>>> that server is finding someone who knows enough C++ and is either
>>> familiar enough with the RFCs or willing to /become/ familiar enough
>>> with them to create and submit a patch...
>>
>> I have a "hackish" fix to it for now... I working on more "proper" fix
>> to it after working out how this thing works... since its not my code
>> originally.... my original initial fix didn't work because of the way
>> it parses commands...
>>
>> I have a fix... and working on adding some other things...
>>
>> Based on the RFC's a client *SHOULD*
>>
>> Connect to SERVER
>>
>> CAPABILITIES parse that for commands (optionally switch to Secure mode)
>> based on this, rinse repeat CAPABILITIES after switching to secure
>> mode)
>> MODE READER if above CAPABILITIES parse again LIST
>>
>> But the clients I checked with, 3, Pan, Knode, and thunderturkey don't
>> issue CAPABILITIES.
>>
>> Just issue MODE READER and go from there....
>>
>> So seems that there is a diversion away from the proper route and the
>> quick route ....
>>
>> Doesn't seem to be a complete definitive answer here as it seems all
>> servers and clients have gotten away from the RFC's....

DLSauers--

Per Hedeland's superb post made me think several times before posting
this lame offering, but what the hell, I have no ego ;-)

I am not a coder and can only sort-of follow what you are discussing, but
I am a willing and somewhat experienced Willing Laboratory Lab Animal and
can do gdb backtraces and such if told what parameters to use.

So what I'm saying is, although I will be less than useless in helping
you code a fix for this very real problem in any commit-worthy sense of
the word, I might be able to help if you need sacrificial test critters
that you have to unscrew the tops of the head of in order to pour in your
desired instructions.

Just offering ;-)

I care very much about the Pan project and am always eager to see it
advance in any particulars.

You may get some idea of the level of my Sacrificial Lab Animal
usefulness from this rather dated example for another project. I suppose
it could help you decide whether I would be of any use):

http://pastehtml.com/view/5tx16jw.html

... hey, at least I didn't <shudder> *top post* ;-)

--
Lacrocivious Acrophosist

Twice as crazy as I would be, if I was half as crazy as I am.


_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC versus sever versus client

altbinspam (Bugzilla)
On Fri, 11 Nov 2016 04:19:10 +0000, Lacrocivious Acrophosist wrote:

Should have put this in my initial reply.

Petr Kovar and I managed some years ago to exhume the Pan IRC channel
from pliestocene sediment, and I got FreeNode to give me chanop for it,
so the Pan IRC channel exists at irc.freenode.net #pan ... and it is kept
alive for just such brainstorming what as may be useful to devs in the
heat of inspired fugue such as this might be ;-)

mikedld used it for a bit, so it has been proven harmless insofar as
regulars here may attest.

By rights Duncan should own and 'run' it, as he is the nexus constant to
this project through thick and thin, but he prefers the newsgroup and no
one can fault him for that.

Anyway, if anyone wants to use it for Pan stuff, it's there.

--
Lacrocivious Acrophosist

Twice as crazy as I would be, if I was half as crazy as I am.


_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC versus sever versus client

altbinspam (Bugzilla)
On Fri, 11 Nov 2016 04:52:51 +0000, Lacrocivious Acrophosist wrote:

Dammit. I misspelled 'pleistocene'. How can I live with this shame?

--
Lacrocivious Acrophosist

Twice as crazy as I would be, if I was half as crazy as I am.


_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC versus sever versus client

altbinspam (Bugzilla)
On Fri, 11 Nov 2016 04:59:55 +0000, Lacrocivious Acrophosist wrote:

> On Fri, 11 Nov 2016 04:52:51 +0000, Lacrocivious Acrophosist wrote:
>
> Dammit. I misspelled 'pleistocene'. How can I live with this shame?

Snakes on everything. I also said 'mikedld used it for a bit', he being a
dev on another project (very) loosely chronologically-dev-related to this
one, when I meant to say Heinrich Müller, who actually contribute(s/d) to
*this* project. Obviously I should stop now.

--
Lacrocivious Acrophosist

Twice as crazy as I would be, if I was half as crazy as I am.


_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC versus sever versus client

Per Hedeland
In reply to this post by Per Hedeland
On 2016-11-11 05:17, DLSauers wrote:
> On Thu, 10 Nov 2016 23:12:16 +0100, Per Hedeland wrote:
>

[snip]

>> And regarding Duncan's mention
>> of what is known as "Postel's principle", a resonable application of
>> that is that if you are an NNTP server that only provides reader
>> service, and a client asks you for reader service, you just say "sure,
>> go ahead" - while a client ignoring an error response from the server
>> may not be, since it can lead to all kinds of difficult-to-debug
>> problems down the line.
>
> That sounds logical but the way that server is written.. It doesn't work
> that way.

Obviously not:-) - if it did, this discussion wouldn't be needed.

> Connection
> 200 sever intro blah blah blah
> MODE READER
> 500 Unknown Command
>
> At this point */PAN/* goes offline, its  done. Refuses to do anything
> with any other server. You can't get a list of groups from this server.

Understood. A 5xx reply code indicates a fatal error, and the client
giving up on the server and disconnecting is the "normal"/default
behavior (if it affects Pan's behavior towards *other* servers, that's
another thing - may or may not be a bug, but perhaps we can leave it out
of this discussion). In principle a standard could specify some kind of
"trial and error" protocol, and say that "If command X generates a 500
reply, try command Y instead" or even "Always ignore the reply to
command X", but I've never seen that. Absent such specifications, it is
ultimately up to the implementor (and users) of the client do decide
which client behavior that is most *useful* when a specific command
returns a specific 5xx code. But giving up and disconnecting can not be
considered *wrong*.

>> Anyway, enough rambling - I think the answer, maybe not to your actual
>> question but to the question of what needs to be fixed, is perfectly
>> clear from RFC 3977 - and it is what you could expect from a standard
>> created by people that actually *have* the historical perspective. It
>> says:
>>
>> In section 5.2.2, about the CAPABILITIES command:
>>
>>    This command MAY be issued at any time; the server MUST NOT require
>>    it to be issued in order to make use of any capability.
>
> To me that sounds, well illogical, and that you are ASSUming stuff...

This is what the standards-track RFC says - it is as close to the law
that you get on the Internet, and how it sounds to you or anyone else
doesn't matter. If your implementation doesn't do what it says, it is
not standards-compliant. The *reason* for this wording is in the
background I described earlier - the people behind RFC 3977 are smart
and well aware of that background, and realise that they can not, after
20 years without evolving standards support for implementors, publish an
RFC that, if implemented by a server, would make every existing client
implementation unable to use that server. Thus a compliant server MUST
implement the CAPABILITIES command that they invented, but it MUST NOT
require that a client makes use of it.

>> In section 5.3.2, about the MODE READER command:
>>
>>    If the server is not mode-switching, then the following apply:
>>
>>    o  If it advertises the READER capability, it MUST return a 200 or
>>       201 response with the same meaning as for the initial greeting; in
>>       this case, the command MUST NOT affect the server state in any
>>       way.
>
> This server does not implement CAPABILITIES so it can't advertise its
> capabilities.

Hm, I actually thought that you said that earlier, but assumed that I
must have misunderstood. RFC 3977 says in 5.2.1 about CAPABILITIES:

   This command is mandatory.

(And in 3.4: "... some of the commands in this specification are
mandatory (they must be supported by all servers) ...".)

I.e. if the server in question does not implement CAPABILITIES, it is
not compliant with the current NNTP standard (probably most of the
world's NNTP servers aren't) - so why all the fretting about what the
RFCs say? If they don't care about compliance with the current standard,
the only reasonable alternative is to implement "best current practice"
- that does require some research, but it shouldn't take much to figure
out that "proper implementation of the MODE READER command, without
requiring that some other command has preceded it" is part of it.

>> If the implementation of the server in question is done per the letter
>> of 3977, it surely advertises the READER capability,
>
> The server in question does NOT respond to:
>
> Does not implement 3977
>
> CAPABILITIES
> MODE READER

As already noted, MODE READER predates 3977 by a decade and a half.

> And is not a mode switching ie, since it lacks support for IHAVE, etc..
> and unless you disable it you have to AUTHINFO to login to post..which in
> doing so would allow spam, but also break Fido Policy 4 rules, which
> require authenticated posting.
>
> The transport of articles obviously occurs via FTN ie: binkd mostly
> today, so thats why it doesn't do IHAVE.

Understood, but irrelevant, whether it is standards-compliant (3977 says
that it MUST implement MODE READER even if it is a reader-only server)
or not (the client has no way of knowing that it is a reader-only
server).

> That is what I did, I added a response  200 to this... as it appeases Pan
> and Knode to work with this software...

Yes, per above this is what an NNTP server that provides reader service
*should* do. (Though note well that the reply can alternatively be 201,
and that there is an important difference.)

> If the CAPABILITIES command is not around for a client to parse what the
> server supports, what is it for???

Of course it is for that, and the idea is very good, and commonly
included from day one when new protocols are specified. But it didn't
exist in NNTP before RFC 3977 was published, and the server clearly
doesn't implement it, so it's pretty moot in this discussion I think.

--Per

_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC versus sever versus client

Per Hedeland
On 2016-11-11 15:38, DLSauers wrote:

> On Fri, 11 Nov 2016 10:08:31 +0100, Per Hedeland wrote:
>
>> Understood. A 5xx reply code indicates a fatal error, and the client
>> giving up on the server and disconnecting is the "normal"/default
>> behavior
>
> Pan and KNode do this...
>
> The monkey in the works is: thunderturkey
>
> Connect
> 200 Sever blah blah
> MODE READER
> 500
> LIST
>
> It just ignores the 500 and continues on so it works to get the initial
> group list, thus you can do all the other things, read, post etc..

Yes, you already said so:-) - and I didn't say that it is wrong to do so
either, on the contrary:

>> Absent such specifications, it is
>> ultimately up to the implementor (and users) of the client do decide
>> which client behavior that is most *useful* when a specific command
>> returns a specific 5xx code.

And in the specific case of the MODE READER command, with the specific
reply code 500 - which means "Command not understood" - it is useful,
and can even be considered reasonable, to ignore the reply. The client
doesn't *need* any result from the command (unlike e.g. LIST) in order
to proceed - it is just issuing it because some *servers* need it to be
issued in order to allow reader commands such as LIST. (In INN, a
special "reader service" program 'nnrpd' is forked at that point - the
reader commands are not implemented in the "main" 'innd' program which
is dedicated to "feeder service".)

I.e. if the server says "Command not understood" in response to MODE
READER, it obviously does *not* need that command, and it's perfectly OK
for the client to go on with its reader business.

> A HUGE HAMMER TO HIT THEM ON THE HEAD! They are very pedantic if it aint
> in the RFC we don't have to do it that way, and since server x doesn't
> support RFC xxxx F off!

Seems like a very self-contradicting principle.:-)

> What I after is
>
> RFC xxxx says do this! Period.

As I already showed, RFC 3977 does indeed say that a server should
support MODE READER - but I can't see how that is useful to you, when
they don't claim to support 3977 anyway.

> Again, what I am after is the supporting "law" of the land as it were...
>
> Bluntly, I am not really caring what RFC xxx or RFC yyy says...

It seems you are also rather self-contradicting.:-)

> This is listed in 3977, but if predates 3977, then what RFC is it in??

Please re-read my original message. It is not in any RFC preceding 3977,
because there was no RFC for it to be in. (Well actually it is in RFC
2980 too, but that's not a specification or a standard, just a
collection of useful info.) RFC 977 was published in 1986, by the same
people who also did the very first implementation (this was back in the
days where "RFC" actually meant what the acronym expands to).

For the following 20 years, where perhaps the first 10 saw the most
dramatic evolution in the use of NNTP transport for Usenet News, there
was nothing. But of course this didn't mean that developers who needed
new functionality in the protocol just gave up on it - they discussed
with others in their community, and implemented what they needed. And
when INN was the only game in town if you wanted a performant server,
and it required the MODE READER command for reader service, of course
"all" the client developers implemented it.

As I wrote, it's great that 3977 now exists, but it is pretty much too
late. AFAIK current INN implements it, but I wouldn't be surprised if
it's the only server that does, and I can't see support being added to
existing clients - there's simply no need for it.

> server x supports most of the basic NNTP protocol as specified in RFC-977.
> The commands IHAVE, NEWGROUPS and NEWNEWS are not implemented, but at
> least
> give valid response codes if a newsreader tries to use them. server x also
> supports the XOVER and AUTHINFO commands as specified in RFC-2980. XOVER
> never sends information about the line counts and byte counts of messages.

This is a perfectly reasonable approach I think, and with such a
statement, arguing that there is some "law" that says that they must do
this or that seems completely pointless. What I don't understand is why
they would be so violently opposed to a trivial MODE READER
implementation, with the simple argument that some readers expect it.
Perhaps you are just using the wrong approach?:-)

> Doing what I've done for now with my solution 200 will work to appease
> Pan, Knode..
>
> 201 would require the server to check that AUTHINFO has been done, a
> valid login has been done, to present the 201 response..as only if you
> logged in can you post, it also depends on the group the user is in.

No, it is not the intent that the 200 vs 201 reply should care about
such things, it is rather a property of the server whether posting is
allowed or not. It should be the same code that is given when the client
initially connects.

> You and/or others seem to better grasp these RFC's.. I read them and they
> seem to contradict themselves....

I think it may just be that you expect to find things that typically
aren't there...

> It appears that KNode at one time in the 0.7x range worked as its listed
> as a compatible client.. obviously later versions tightened up the code
> to follow RFC, and thus no longer work...Pan from .133 to .139 don't.

I have never looked at the KNode code, and I'm not sure if you are
suggesting that earlier versions of Pan worked - but I'm pretty sure
that no developer has made an intentional decision to change from
accepting a 5xx response to MODE READER to not doing it - it just
doesn't make sense, and has the potential for causing completely
unnecessary problems.

But a code reorganization could very well have caused it, and looking at
the current Pan code, I can *imagine* that even Pan accepted 5xx before
the multi-server support was implemented. If your reader only talks to a
single server, an implementation that just goes send-a-command -
wait-for-response - analyse-response is nice and straightforward to
write - and in such an implementation it is also more straightforward to
ignore a "bad" reply to a specific command.

With a good implementation of multi-server support on the other hand,
you don't want to write the code like that - you want to be able to
issue commands to the different servers in parallel, and proceed at a
rate appropriate for each server, not always having to wait for the
slowest one to reply. So you decouple the sending of commands and the
reading of responses, and process the responses (when they arrive) in a
way that is independent of the command given.

In any case, that's what Pan's current code looks like - and as far as I
can see, if it gets a 5xx response, it's end of story (for that server
at least), regardless of what the command was. It *could* be changed...

> Part of what I am going to do is implement CAPABILITIES in at least the
> basic form..

This would be completely pointless - what do you hope to achieve by
that?

> I just want to nail down that per the NNTP protocol the server really
> should have implemented MODE READER, the fact that other clients are more
> lax in requiring it does not mean its not REQUIRED. Correct?

If a server claims to implement RFC 3977, my reading is that MODE READER
support is required. If a server doesn't claim to implement any RFC,
nothing is required. In that case, a reasonable approach is to make as
many clients as possible happy, as long as it doesn't take an
unreasonable amount of effort.

--Per

_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC versus sever versus client

Per Hedeland
On 2016-11-12 15:43, Per Hedeland wrote:

>
> And in the specific case of the MODE READER command, with the specific
> reply code 500 - which means "Command not understood" - it is useful,
> and can even be considered reasonable, to ignore the reply. The client
> doesn't *need* any result from the command (unlike e.g. LIST) in order
> to proceed - it is just issuing it because some *servers* need it to be
> issued in order to allow reader commands such as LIST. (In INN, a
> special "reader service" program 'nnrpd' is forked at that point - the
> reader commands are not implemented in the "main" 'innd' program which
> is dedicated to "feeder service".)
>
> I.e. if the server says "Command not understood" in response to MODE
> READER, it obviously does *not* need that command, and it's perfectly OK
> for the client to go on with its reader business.
...and in case there is interest in it, the attached patch for Pan does
just that - I've tested it against what I believe is the server the OP
is referring to, in any case it is one that does return 500 for MODE
READER.

--Per

PS It so happens that Pan also uses MODE READER as a "keepalive
function", i.e. it is issued periodically as a no-op to keep server
connections alive...

_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users

pan.diff (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC versus sever versus client

Per Hedeland
On 2016-11-12 16:58, Per Hedeland wrote:
>
> ...and in case there is interest in it, the attached patch for Pan does
> just that - I've tested it against what I believe is the server the OP
> is referring to, in any case it is one that does return 500 for MODE
> READER.

Now also attached to https://bugzilla.gnome.org/show_bug.cgi?id=772116

--Per

_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC versus sever versus client

Rhialto
In reply to this post by Per Hedeland
On Sat 12 Nov 2016 at 16:58:32 +0100, Per Hedeland wrote:
> ...and in case there is interest in it, the attached patch for Pan does
> just that - I've tested it against what I believe is the server the OP
> is referring to, in any case it is one that does return 500 for MODE
> READER.

How likely is it that more commands in the future will require similar
treatment? As it is for one command now, this very specific hack works,
but it won't be a great solution for the general case (if needed).

Now personally I'm not a fan of abstracting things when it is not yet
needed but when it is complicated, so I'd propose that if a more general
solution turns out to be indeed complicated and hard to follow, that it
isn't done (yet).

(And now that I am looking at the code in nntp.cc, I see some complexity
that I don't see the need for (yet?). In functions like
list_newsgroups(), a command is queued, and then the first command from
the queue is sent to the server. Who guarantees that the queue was empty
before, and that this is the just-queued command? Yes, the _listener
member is set with just this assumption. Either the assumption should be
checked, or better yet, if possible, the whole queue should be removed
and replaced with a single ""current command". That also makes it simple
to add a flag for "ignore any errors on this command".)

-Olaf.
--
___ Olaf 'Rhialto' Seibert  -- Wayland: Those who don't understand X
\X/ rhialto/at/xs4all.nl    -- are condemned to reinvent it. Poorly.

_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users

signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC versus sever versus client

Per Hedeland
On 2016-11-13 13:07, Rhialto wrote:
> On Sat 12 Nov 2016 at 16:58:32 +0100, Per Hedeland wrote:
>> ...and in case there is interest in it, the attached patch for Pan does
>> just that - I've tested it against what I believe is the server the OP
>> is referring to, in any case it is one that does return 500 for MODE
>> READER.
>
> How likely is it that more commands in the future will require similar
> treatment? As it is for one command now, this very specific hack works,
> but it won't be a great solution for the general case (if needed).

Agreed. I'm not sure about the answer to the question - looking at the
currently implemented commands, I think that MODE READER is unique in
that a 500 response isn't an actual problem - for the others, I think it
really should be considered fatal. But of course additional commands may
be added in the future.

> Now personally I'm not a fan of abstracting things when it is not yet
> needed but when it is complicated, so I'd propose that if a more general
> solution turns out to be indeed complicated and hard to follow, that it
> isn't done (yet).

I can certainly imagine solutions that are "cleaner" without being
complicated or hard to follow, they will just take rather more effort
(and "risk") to implement. Basically amounting to having the caller
handle the error, either as you suggest below, stating up-front that
(some) errors can be ignored, or getting to deal with the error in the
result.

As far as I can see though, either way would require significant
restructuring of the code, in particular for the relevant handshake()
function, where (including the "empty" initial one) 3 commands and
replies are "bundled", and only one of them may fail. Though maybe
"unbundling" MODE READER and having the caller of handshake() do that
separately could be a way.

> (And now that I am looking at the code in nntp.cc, I see some complexity
> that I don't see the need for (yet?). In functions like
> list_newsgroups(), a command is queued, and then the first command from
> the queue is sent to the server. Who guarantees that the queue was empty
> before, and that this is the just-queued command? Yes, the _listener
> member is set with just this assumption. Either the assumption should be
> checked, or better yet, if possible, the whole queue should be removed
> and replaced with a single ""current command". That also makes it simple
> to add a flag for "ignore any errors on this command".)

I don't know if there is an actual problem there, given how the functions
are used - in any case many of them depend on queueing up multiple
commands, in particular prepending a GROUP command to the "actual" one.
But having a more structured queue than a list of strings would
certainly help for a "cleaner" solution. Note though that in this case,
I really think it is *only* the 500/ERROR_CMD_NOT_UNDERSTOOD error that
should be ignored. The others indicate that the server actually
"understood" the command but rejected it - this could e.g. be the case
for a "feeder-only" server that doesn't provide reader service at all,
and Pan should really treat that as a fatal error.

--Per

_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Loading...