pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pan-users] RFC versus sever versus client


From: Duncan
Subject: Re: [Pan-users] RFC versus sever versus client
Date: Thu, 10 Nov 2016 03:27:14 +0000 (UTC)
User-agent: Pan/0.141 (Tarzan's Death; GIT 4e0db5ff8)

DLSauers posted on Thu, 10 Nov 2016 02:16:58 +0000 as excerpted:

> I am looking to have a definitive PER *_RFC_* answer that a client
> regardless of SERVER should issue MODE READER, get 500, done, click! Or
> do what one client does, ignore the 500 issue LIST and go on....

I'll punt for the moment on what you're asking for, but never-the-less, 
here's my immediate thoughts.

A practical and common RFC guideline and general policy is: Interpret the 
RFCs strictly in what you send, but be more tolerant in what you are 
prepared to receive.

In this case, that would mean that regardless of whether the RFCs mandate 
MODE READER or not, particularly given that there are known servers out 
there that don't support it, pan should be prepared to work around 
receiving an error for the command, and continue without it the best it 
can.

I /was/ going to suggest that a workaround would be using a firewall to 
block the 500 error response and replace it with a synthetic response 
that looks more like what pan expects.  However, I expect once pan got 
that, it would continue making requests as if it were in reader mode, so 
it's not as simple as that, as a whole bunch of translation and synthetic 
response generation would need to be done.

Which means the only real solution if you're going to use pan with that 
server is finding someone who knows enough C++ and is either familiar 
enough with the RFCs or willing to /become/ familiar enough with them to 
create and submit a patch...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




reply via email to

[Prev in Thread] Current Thread [Next in Thread]