➜
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2009-02-10 19:42 by travis, last changed 2022-04-11 14:56 by admin. This issue is now closed.
| Files | ||||
|---|---|---|---|---|
| File name | Uploaded | Description | Edit | |
| nntplib.diff | travis, 2009-02-10 21:59 | nntplib.py diff | ||
| Messages (4) | |||
|---|---|---|---|
| msg81587 - (view) | Author: Travis Hassloch (travis) | Date: 2009-02-10 19:42 | |
RFC 977 has been obsoleted by RFC 3977 Numerous new commands, standardized extensions, clarifications. |
|||
| msg81608 - (view) | Author: Travis Hassloch (travis) | Date: 2009-02-10 21:59 | |
Attached is a difference which implements CAPABILITIES and MODE READER and leaves some TODO comments for other RFC 3977 commands. |
|||
| msg122643 - (view) | Author: Julien ÉLIE (jelie) | Date: 2010-11-28 09:25 | |
> + Whether posting is allowed depends on whether it > + is included in results of CAPABILITIES; see > + RFC 3977 section 5.1.2. > + Deprecated: > If the response code is 200, posting is allowed; > if it 201, posting is not allowed.""" 200 and 201 do not have a deprecated meaning in RFC 3977. 200 = posting may be available during the session (possibly after commands like STARTTLS or AUTHINFO have been successfully sent) 201 = posting will never be allowed in the session, whatever the user does. I agree that the only way to know whether posting is allowed at a given time during the session is to send CAPABILITIES and to look for POST. |
|||
| msg245343 - (view) | Author: Martin Panter (martin.panter) *  |
Date: 2015-06-14 13:55 | |
General RFC 3977 support was added as part of Issue 9360 (revision 0077ee30134c), so I am closing this one. For the record there are a couple bits of the patch that someone might still find useful: * New NNTP(bind=...) parameter * More lenient checking for successful authentication status |
|||