Re: [Pan-users] Re: Pan 0.132 - Problem with news.ecomstation.nl

[Per Hedeland]

Duncan <address@hidden> wrote:
>
>Kai Wuttke <address@hidden> posted
>address@hidden, excerpted below, on  Thu, 24 Jul 2008 16:48:52
>+0200:
>
>> If the problem at Pan or the news server?
>
>Well, it could be said to be at both.

But it's actually pan...

>If the server isn't implementing something the RFC says is mandatory, 
>that's a problem.
>
>That said, the advice when coding up RFC implementations has always been 
>(paraphrased) "Be tolerant in what you accept, strict in what you send."  

True, though it's occasionally questioned since it leads to a lot of
sloppy implementations being "tolerated", which may have a variety of
bad effects - but it's certainly true for NNTP, which has existed for
two decades (not one, that's a bug in RFC 3977:-) without a formal
standard.

The original RFC 977 (which predates the concept of formal "standards
track" RFCs, and unlike most of the other "old" protocol RFCs has never
been "grandfathered in") laid down the basics, but since it was
published there has been tons of extensions and even modifications to
deal with the ever-changing demands of Usenet. Writing any kind of NNTP
software has required far more than reading the RFC and being "liberal
in what you accept", you've basically had to collect a lot of "lore"
about how things *really* work to have any hope of success.

There has been a lot of work, head-scratching, and hair-pulling over at
least the second of those two decades in attempts to produce an updated,
"formal" standard, and after a number of failures it has at last
happened with RFC 3977. But this RFC doesn't just document existing
practice, it also adds stuff that was never generally implemented
before, like the CAPABILITIES command - and of course publishing the RFC
doesn't magically cause implementations of that stuff to pop up in all
the existing software out there.

I.e. if a news reader implements (e.g.) the CAPABILITIES command, it
will probably have to be prepared for the "500 Command unrecognized"
response for another two decades or so. I'm not sure why walt brought
this up though, since pan doesn't implement/use CAPABILITIES, i.e.
there's no problem there - the problem is (as he pointed out) with the
503 response to the "LIST NEWSGROUPS" command - and this is a plain pan
bug.

503 is a perfectly valid response here - RFC 977 has it as "program
fault - command not performed" which sounds a bit drastic, but it's
clear that the command failed and that trying it again isn't likely to
help - but in pan's NNTP code it's specified as

      ERROR_TIMEOUT              = 503

- which seems pretty bizarre to me, I have no idea where it's coming
from. It doesn't make any sense for the server to *say* that a timeout
occurred, that would be something the client notices by way of the
*lack* of a response - and the pan code handles it as if the latter had
happened (i.e. closes the connection and opens a new one, with the same
result).

The trivial patch below seems to fix the problem (using the RFC 3977
definition for the "code name").

--Per Hedeland

--- pan-0.132/pan/tasks/nntp.cc.ORIG    2007-08-01 19:00:00.000000000 +0200
+++ pan-0.132/pan/tasks/nntp.cc 2008-07-27 22:49:19.000000000 +0200
@@ -92,7 +92,7 @@
       ERROR_CMD_NOT_UNDERSTOOD   = 500,
       ERROR_CMD_NOT_SUPPORTED    = 501,
       NO_PERMISSION              = 502,
-      ERROR_TIMEOUT              = 503
+      FEATURE_NOT_SUPPORTED      = 503
    };
 }
 
@@ -230,7 +230,8 @@
       case NO_GROUP_SELECTED:
       case ERROR_CMD_NOT_UNDERSTOOD:
       case ERROR_CMD_NOT_SUPPORTED:
-      case NO_PERMISSION: {
+      case NO_PERMISSION:
+      case FEATURE_NOT_SUPPORTED: {
          std::string cmd (_previous_command);
          if (cmd.size()>=2 && cmd[cmd.size()-1]=='\n' && 
cmd[cmd.size()-2]=='\r')
            cmd.resize (cmd.size()-2);
@@ -249,7 +250,6 @@
          state = CMD_FAIL;
          break;
 
-      case ERROR_TIMEOUT:
       case TOO_MANY_CONNECTIONS:
          state = CMD_RETRY;
          break;