Invalid 431 response when server is paused

River Tarnell river at RT.UK.EU.ORG
Sun Jan 1 20:58:05 UTC 2012

In article <4F0098AE.4010206 at>,
Julien ÉLIE  <julien at> wrote:
>> CHECK<a at b>
>> 431 testing

>With the patch:

>I now see the right behaviour:

>CHECK <test at test>
>431 <test at test> testing

Excellent :-) Thanks.

>Incidentally, does the feeder you are speaking about properly handle
>the 400 response code innd gives when paused and TAKETHIS is used?

It will handle it, but only in the same way it handles any unexpected[0]
response: it will disconnect, wait about 60 seconds, then reconnect and 
try again with the same message-id.  At the moment I never send a 
TAKETHIS without a prior CHECK, so if TAKETHIS <a at b> replies with 400, 
the next command in the new connection will be CHECK <a at b>.

[0] By which I mean "not 239 or 439".

>And, more subtle, does it handle 501 response codes?

No.  Or rather, it does the same thing as 400: it will try to re-send 
the article later.  So if the remote server is more strict about 
message-ids than we are, the queue would block trying to send the same 
article forever.

I just noticed one case where this could happen:

200 RT/NTS 1.0-CURRENT ready -- transit service only (news at RT.UK.EU.ORG).
CHECK <a@@b>
238 <a@@b>

200 InterNetNews server INN 2.5.2 ready (transit mode)
CHECK <a@@b>
438 <a@@b>

Of course, since INN doesn't actually send 501 at the moment, we avoid 
the problem here.

This wasn't a deliberate design decision, I just didn't implement any 
special handling for it yet.  I think the right (RFC-compliant) response 
is to treat it as 438, unless there are servers which can return 501 for 
other reasons.

For reference, the feeder source is here: 
<> (mostly the 
fe_running() function).

        -- river.                      | Free Usenet:
Non-Reciprocal Laws of Expectations:   | PGP: 2B9CE6F2
    Negative expectations yield negative results.
    Positive expectations yield negative results.

More information about the inn-workers mailing list