Message153229
So my take on the whole issue and Antoine "tends to agree". ;)
1. If the user tells us (s)he _wants_ us to authenticate or send MODE READER, we do it even if capabilities don't advertise it. There's a lot of rfc-non-conformant servers out there. Permanent errors (i.e. not supported) will be gracefully swallowed.
That's already status quo.
2. If the server tells us it already _is_ in READER mode, we don't send it because in that case we can assume the server knows what it's doing.
The next patch checks whether we're in READER mode before trying to switch the mode.
I've also added a test for the basic case where a connection is made to a MODE-READER advertising server.
I also added a handler to the nntp2 tests that raises an exception if "mode reader" is called although the server advertises itself as "reader".
If there's a consensus of not sending "MODE READER" if not advertised, it's a matter of two lines to fix that. Personally, I like this middle ground best. |
|
Date |
User |
Action |
Args |
2012-02-12 21:03:29 | hynek | set | recipients:
+ hynek, pitrou, jelie, python-dev, Nathan.Clayton |
2012-02-12 21:03:28 | hynek | set | messageid: <1329080608.95.0.0424941034685.issue10287@psf.upfronthosting.co.za> |
2012-02-12 21:03:28 | hynek | link | issue10287 messages |
2012-02-12 21:03:28 | hynek | create | |
|