delphi - TIdNNTP fallback to XOVER for legacy/non-compliant NNTP server -
i using tidnntp
, encountered situation news.astraweb.com server announces in list extensions
supports new command hdr
, over
(formal versions of xhdr
, xover
) - see http://tools.ietf.org/html/rfc3977#section-8.3 , http://tools.ietf.org/html/rfc2980#section-2.8
the problem server replies command code 500 (invalid command) when issued on command (instead of xover). although non-rfc-compliant behavior i'd see if there possibility force tidnntp
use xover instead of over, in other words work in sort of "legacy" mode. same thing works compliant server news.aioe.org
log example news.astraweb.com (problematic server)
->capabilities <-500 what? ->list extensions <-202 extensions supported: <-hdr <-over <-. ->group group.name <-211 100031 1 100031 group.name ->over 100031-100031 <-500 what?
proper log news.aioe.org (works expected)
-> capabilities <- 101 capability list: <- version 2 <- implementation inn 2.5.2 <- authinfo <- sasl <- hdr <- list active active.times distrib.pats headers newsgroups overview.fmt <- on <- post <- reader <- sasl ntlm digest-md5 cram-md5 <- starttls <- . -> starttls <- 382 begin tls negotiation -> mode reader <- 200 news.aioe.org internetnews nnrp server inn 2.5.2 ready (posting ok) -> capabilities <- 101 capability list: <- version 2 <- implementation inn 2.5.2 <- authinfo <- user <- sasl <- <- hdr <- list active active.times distrib.pats headers newsgroups overview.fmt <- on <- post <- reader <- sasl ntlm digest-md5 cram-md5 plain login <- . -> group group.name <- 211 4540 67027 71566 group.name -> on 67027-71566 <- 224 overview information 67027-71566 follows ....
right now, tidnntp
automatically selects on when server announces supports on , using idnntp.xover
call issue on command. can overridden somehow? worth bothering doing sort of legacy support?
tidnntp
hard-coded use over
if server claims support over
, , likewise hdr
. there no option change that. have call sendcmd()
directly, can process response want.
personally, contact astraweb.com , let them know nntp server broken. went trouble of implementing newer capabilities
command, violated core requirement of it:
the server must ensure capability list accurately reflects capabilities (including extensions) available.
i not inclined change indy's behavior because 1 server non-conforming. if there other servers exhibit same faulty behavior, adding fallback option make more sense.
Comments
Post a Comment