[ python-Bugs-1753732 ] xmlrpclib.Binary doesn't say which base64 spec it implements
Bugs item #1753732, was opened at 2007-07-13 20:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753732&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Winkler (slinkp) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib.Binary doesn't say which base64 spec it implements Initial Comment: xmlrpclib.Binary.encode() does base64 encoding. But there are actually two conflicting specs: RFC 2045 says add newlines every 76 characters, RFC 3548 says do NOT add newlines. The xmlrpc spec characteristically doesn't mention an RFC, so it's not clear which spec they mean by "base64". By looking at the dates on the various specs, it can be inferred that they must mean MIME-style with newlines, as per RFC 2045. That's xmlrpclib does. But for those of us implementing stuff in the trenches and struggling with interoperability issues, it would be nice if the python docs were more informative so we don't have to go spiraling off into reading multiple specs and figuring out which came first :) So I'd suggest changing the Binary.encode docstring to something like: """Write the XML-RPC base 64 encoding of this binary item to the out stream object. Note that the encoded data will have newlines every 76 characters as per RFC 2045, which was the de facto standard base64 specification when the xmlrpc spec was written.""" Arguably, the behavior could be changed instead - due to the xmlrpc spec's silence on the subject, not all clients may tolerate newlines (Redstone doesn't)... but that's a separate argument :) -- >Comment By: Martin v. Löwis (loewis) Date: 2007-07-14 14:51 Message: Logged In: YES user_id=21627 Originator: NO Note that RFC 3548 is informational, so it is not a specification (at least not of an internet protocol). Also notice that Python's xmlrpclib library is not the specification or de-facto implementation of XML-RPC, either. The official XML-RPC specification is at http://www.xmlrpc.com/spec According to that specification, the only possibilities are that Python's implementation is either conforming or not conforming. If it is not conforming, it should be changed; if it is conforming, it should stay, and Redstone should be changed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753732&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1753718 ] base64 "legacy" functions violate RFC 3548
Bugs item #1753718, was opened at 2007-07-13 20:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753718&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Winkler (slinkp) Assigned to: Nobody/Anonymous (nobody) Summary: base64 "legacy" functions violate RFC 3548 Initial Comment: (Python 2.5.1 and earlier) Apologies for how long this is, but cleaning up history is hard. There seems to be a lot of historical confusion around Base 64 encoding, and unfortunately the python library docs reflect that confusion. The base64 module docs (at http://docs.python.org/lib/module-base64.html ) claim to implement RFC 3548, as seen at http://www.faqs.org/rfcs/rfc3548.html ... heck it's even in the page title. (I'll quickly note here that RFC 3548 has recently been obsoleted by RFC 4648, but for purposes of this bug report the two RFCs are the same so I'll just refer to 3548.) But the "legacy" functions, encode() and encodestring() , add line feeds every 76 characters. That is a violation of RFC 3548, which specifically says "Implementations MUST NOT add line feeds to base-encoded data". RFC 4648 says the same thing. Obviously we can't change behavior of legacy functions, but I strongly feel the docs should warn you about this violation. What encode() and encodestring() actually implement is MIME base 64 encoding, as per RFC 2045 (see http://tools.ietf.org/html/rfc2045#section-6.8 ... obsoletes 1521, 1522, 1590) So base64.encodestring() is AFAICT functionally identical to email.base64mime.encodestring (tangent: someday we should consolidate those two functions into one implementation). What RFC 3548 describes IS implemented by the "modern" interface such as base64.b64encode(), which does not split into lines. There's also the lower-level binascii.b2a_base64() function which afaict correctly implements RFC 3548 (although it adds a newline at the end, which base64.b64encode() does not; it's not clear to me which is correct per RFC 3548.) At one time, b2a_base64 DID split into lines, but that was fixed: http://sourceforge.net/tracker/index.php?func=detail&aid=473009&group_id=5470&atid=105470 . But unfortunately, its docs still mistakenly say "The length of data should be at most 57 to adhere to the base64 standard." which presumably refers to the old PEM spec that predates even MIME. So I propose several doc changes: 1) Add a reference to RFC 3548 and/or 4648 to the binascii docs, and remove the cruft sentence about "at most 57". 2) Add a sentence to the base64 docstrings for encode() and encodestring() like this: "Newlines will be inserted in the output every 76 characters, as per RFC 2045 (MIME)." 3) Change the introductory text in the base64 docs to something like this: """There are two interfaces provided by this module. The modern interface supports encoding and decoding string objects using all three alphabets. The modern interface, per RFC 3548, does NOT break the output into multiple lines. The legacy interface provides for encoding and decoding to and from file-like objects as well as strings, but only using the Base64 standard alphabet, and adds newlines every 76 characters as per RFC 2045 (MIME). Thus, the legacy interface is not compliant with the newer RFC 3548. If you are encoding data for email attachments and wondering which to use, you can use the legacy functions but you should probably be using the email package instead. """ -- >Comment By: Martin v. Löwis (loewis) Date: 2007-07-14 14:56 Message: Logged In: YES user_id=21627 Originator: NO I would not say that the older functions violate RFC 4648. They just don't implement it, as they implement some other standard instead. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753718&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1753406 ] subprocess.check_call() new in 2.5
Bugs item #1753406, was opened at 2007-07-13 11:43 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753406&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Yitz Gale (ygale) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.check_call() new in 2.5 Initial Comment: The function subprocess.check_call() should be marked in the documentation as "New in version 2.5". -- >Comment By: Georg Brandl (gbrandl) Date: 2007-07-14 17:13 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the report, fixed in rev. 56364, 56365 (2.5). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753406&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1671676 ] test_mailbox is hanging while doing gmake test on HP-UX v3
Bugs item #1671676, was opened at 2007-03-01 07:24 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671676&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: shashi (shashikala) >Assigned to: A.M. Kuchling (akuchling) Summary: test_mailbox is hanging while doing gmake test on HP-UX v3 Initial Comment: Hi , I am testing Python 2.5 on HP-UX 11iv3 using gmake test , while testing the test test_mailbox.py is hanging . when tried to track the problem i came to know that in the function if pid == 0: # In the child, lock the mailbox. self._box.lock() time.sleep(2) self._box.unlock() os._exit(0) # In the parent, sleep a bit to give the child time to acquire # the lock. time.sleep(0.5) try: self.assertRaises(mailbox.ExternalClashError, self._box.lock) finally: # Wait for child to exit. Locking should now succeed. exited_pid, status = os.waitpid(pid, 0) after forking the child , child is not returning status to the parent while its waiting for the return status. which part of the Python functionality is checked. Please assist me to solve this. Thanks in advance , shashi -- Comment By: shashi (shashikala) Date: 2007-03-31 09:27 Message: Logged In: YES user_id=1506183 Originator: YES please find attached log stacktrace of test_mailbox.py , assist me to analyse the test hang. File Added: python.txt -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671676&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-818065 ] mailbox._Subfile readline() bug
Bugs item #818065, was opened at 2003-10-05 07:09 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818065&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan Perez (jbperez808) >Assigned to: A.M. Kuchling (akuchling) Summary: mailbox._Subfile readline() bug Initial Comment: mailbox._Subfile's readline() will chop off the first character of the next line when reading Unix-style terminated files. It's surprising no one has mentioned this before. The problem lies in line mailbox._Subfile.readline() itself where self.pos is assigned self.fp.tell()'s value. You will need to subtract 1 from self.pos if a file uses unix-style termination. -- Comment By: Jonathan Perez (jbperez808) Date: 2003-10-06 09:33 Message: Logged In: YES user_id=286435 There doesn't seem to be a clean way to fix the code. But there is a rather satisfactory workaround: Open the mbox file in binary mode for Unix (and Mac?) style terminated files. This should DEFINITELY be mentioned in the mailbox module docs. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818065&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
