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 Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users