[issue30909] ServerProxy should not make requests with malformed XML
New submission from Alex Corcoles: https://docs.python.org/3.7/library/xmlrpc.client.html says: """ When passing strings, characters special to XML such as <, >, and & will be automatically escaped. However, it’s the caller’s responsibility to ensure that the string is free of characters that aren’t allowed in XML, such as the control characters with ASCII values between 0 and 31 (except, of course, tab, newline and carriage return); failing to do this will result in an XML-RPC request that isn’t well-formed XML. If you have to pass arbitrary bytes via XML-RPC, use bytes or bytearray classes or the Binary wrapper class described below. """ The XML-RPC spec at http://xmlrpc.scripting.com/spec.html says: """ What characters are allowed in strings? Non-printable characters? Null characters? Can a "string" be used to hold an arbitrary chunk of binary data? Any characters are allowed in a string except < and &, which are encoded as < and &. A string can be used to encode binary data. """ I believe strings should be XML-escaped correctly or at the very least, an assertion should be made to ensure no malformed XML is ever generated. -- components: XML messages: 298226 nosy: Alex Corcoles priority: normal severity: normal status: open title: ServerProxy should not make requests with malformed XML type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue30909> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7727] xmlrpc library returns string which contain null ( \x00 )
Changes by Alex Corcoles : -- nosy: +Alex Corcoles ___ Python tracker <http://bugs.python.org/issue7727> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7727] xmlrpc library returns string which contain null ( \x00 )
Changes by Alex Corcoles : -- versions: +Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue7727> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32060] Should an ABC fail if no abstract methods are defined?
New submission from Alex Corcoles : Hi, $ python3 Python 3.5.3 (default, Jan 19 2017, 14:11:04) >>> import abc >>> class Foo(abc.ABC): ... pass ... >>> Foo() <__main__.Foo object at 0x7f253e6dcb38> I think declaring a class as ABC without declaring any abstract method is an error. I've tried searching if this was already discussed, but did not find it. Maybe it is related to https://bugs.python.org/issue9731 Cheers, Álex -- messages: 306433 nosy: Alex Corcoles priority: normal severity: normal status: open title: Should an ABC fail if no abstract methods are defined? type: behavior versions: Python 3.5 ___ Python tracker <https://bugs.python.org/issue32060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32060] Should an ABC fail if no abstract methods are defined?
Alex Corcoles added the comment: Are you referring to something akin to Java's marker interfaces? That is, a class with no methods which you inherit from just for semantic meaning (e.g. Java's serializable interface that you implement to indicate that the class is designed for pickling). In that case, I suppose the docs could mention this clearly so this is more "discoverable" to noobs like me and prevent further issues like this (I think mine wasn't an unreasonable expectation). In any case, it's a minor point and I don't feel I have enough authority to discuss this topic- it's fine to close this. -- ___ Python tracker <https://bugs.python.org/issue32060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34954] Getting an email's subject is error-prone
New submission from Alex Corcoles : Hi, This is something that has hit us a few times, as we write a significant quantity of software which parses email messages. The thing is, we use email.header.decode_header to decode the Subject: header and it is pretty common for headers to be word-wrapped. If they are, decode_header will return a string with newlines in it. This is something which is unexpected for many people, and can cause bugs which are very difficult to detect in code review or testing, as it's easy to not trigger wordwrapping if not done deliberately. We would humbly suggest to provide a friendly way to get an email's subject in the expected fashion (i.e. with no newlines) or point out this caveat in the docs (or maybe change decode_header to remove newlines itself). Kind regards, Álex -- components: email messages: 327481 nosy: Alex Corcoles, barry, r.david.murray priority: normal severity: normal status: open title: Getting an email's subject is error-prone type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34954> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34954] Getting an email's subject is error-prone
Alex Corcoles added the comment:
To clarify (and maybe help someone which might come across), you mean:
In [1]: message_text = """To: a...@corcoles.net
...: Subject: ** ACKNOWLEDGEMENT Host Alert: archerc7.bcn.int.pdp7.net is
DOWN
...: **
...: User-Agent: Heirloom mailx 12.5 7/5/10
...: MIME-Version: 1.0
...: Content-Type: text/plain; charset=us-ascii
...: Content-Transfer-Encoding: 7bit
...:
...: * Nagios *
...: """
In [2]: import email
In [4]: message = email.message_from_string(message_text)
In [5]: message.get('Subject')
Out[5]: '** ACKNOWLEDGEMENT Host Alert: archerc7.bcn.int.pdp7.net is DOWN\n **'
In [7]: from email import policy
In [8]: message = email.message_from_string(message_text, policy=policy.HTTP)
In [9]: message.get('Subject')
Out[9]: '** ACKNOWLEDGEMENT Host Alert: archerc7.bcn.int.pdp7.net is DOWN **'
Yeah, there's a bundled policy that does what I need, but I think it's not very
intuitive.
I get that the stdlib is deliberately low level in these parts, and it's more
of building block to create higher level libraries on top of that, but still I
feel that getting an email's subject in a friendly fashion should be easy and
intuitive in the stdlib, or the stdlib's docs should point out clearly to go
and look for a higher level library because email is hard.
OTOH, working with mail sucks and should be discouraged, so if you want to
close this definitely I won't complain.
--
status: closed -> open
___
Python tracker
<https://bugs.python.org/issue34954>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34954] Getting an email's subject is error-prone
Alex Corcoles added the comment: Well, I think that having to choose the "HTTP" policy to get a message subject's without newlines goes against the expectations of anyone who is not well knowledgeable of email. It's not very easy to deduct that, out of all the available policies, HTTP is the one that has this effect (or writing your own). It's not obvious that a subject can have newlines, as I don't think I've ever seen a MUA that does not hide them. You can be bitten quite easily by that (we have, more than once). It's the stdlib's maintainers' prerrogative to decide that they are going to provide low-level libraries (and in general, I agree with that, high-level stdlibs have a lot of problems), but at least I'd include some warning like: "Email is an old and annoying protocol, and parsing email is full of annoyances and exceptions. email provides low-level building blocks to handle email in detail. If you want high-level processing we advise you to look at libraries that build on it". In any case, email.policy provides more hints as to headers being wordwrapped, and while it's not ideal, it certainly is an improvement WRT to Python 2, so this bug has helped me and I hope maybe someone will read it when Googling for the same problem, so while I think some more could be done, if you close this I won't complain. Thanks, Álex -- status: closed -> open ___ Python tracker <https://bugs.python.org/issue34954> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34954] Getting an email's subject is error-prone
Alex Corcoles added the comment: Duh, I'm an idiot, I only tested policy.HTTP and *NOT* supplying a policy (which I believed was equivalent to using policy.default). policy.default and policy.SMTP do indeed produce a newline-less subject indeed. I only tested policy.HTTP because the docs talk about unlimited line-length, but that's a problem of the docs, but rather, a problem of my idiocy. Given this, I agree with everything you said. Personally I'd prefer if policy.default was the default, but I guess that won't change due to backwards compatibility reasons and I guess it'd be excessive to create a new set of function calls and deprecate the old, so I'm happy if this remains closed. Apologies for my stupidity, Álex -- ___ Python tracker <https://bugs.python.org/issue34954> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
