Arrgh! latest innfeed crashes like heck!
sven at tin.org
Fri Apr 14 00:41:37 UTC 2000
On 14.04., Barry Bouwsma wrote:
> > Another problem concerning innfeed came up on de.admin.news.misc some days
> > ago: Someone posted an article containing a Message-ID 494 characters long.
> > Now some NNTPRelay and Diablo peers rejected this Message-ID as being too
> > long with an 500 return code (= syntax error).
> Actually, that would have been a `400' response code in the case of
> NNTPRelay (which is where I noticed this problem). I didn't notice
> what the response was for Diablo peers.
Oops, sorry, the problems with diablo were reported by someone else, I was
a little confused ... It's DNEWS which caused the 500 problems:
Apr 11 23:42:55 xxxxxxxx innfeed: yyyyyy:1 cxnsleep response unknown : 500 : 500 command too long
200 yyy.yy.yy.yy DNEWS Version 5.3e3, S0, posting OK
> I used to see this problem with truncated message IDs that would
> bounce around with a `400' error from NNTPRelay, and I think Diablo
Yes, you're right, NNTPrelay answers with 439 giving a truncated ID :(
> I think I'll figure out what the max message length of NNTPRelay and
> Diablo are, and add a sanity check on the length, because those responses
Son of 1036 limits the overall length of a Message-ID to 250 octets. innfeed
could just drop articles with ID which are longer, configurable per peer,
but this isn't a nice solution at all. Being more robust towards broken
peers is better. And before a Message-ID starts looping we should better
drop it ...
What I was thinking about: Is there a possibility that the remote site
shuffles the order of the replys of an CHECK command?
< CHECK <abc at def>
< CHECK <ghi at jkl>
< CHECK <mno at pqr>
> 23x <ghi at jkl>
> 43x <abc at def>
> 23x <mno at pqr>
If this isn't the case, we could just drop the _first_ article in the
take/check-queue if we receive an unknown reply (500 or 2xx or 4xx with
unknown ID) from the remote site.
> at any time. I'd say the site on the other end needs to be fixed, but
Of course, this is the best solution.
> if it's possible to work around the most likely causes of these responses,
> innfeed should do that too.
More information about the inn-workers