[issue17251] LWPCookieJar load() set domain_specifed wrong
Maximiliano Curia added the comment: I've deleted my previous patch, as I found the code working as intended. The domain_specified signals whether the domain stores came from a Domain: tag inside a Set-Cookie request or is taken from the hostname of the request. The rfc2965 dictates that a value taken from a Domain: tag should be prepended with a . if the values doesn't include it. Once stored in a LWPCookieJar the same logic is used to signal if the domain_specified is true or false. Thus the observed behaviour. The LWP-Cookies-2.0 format is an extension to the perl format, that seeks compatibility adding some features. About the domain matching, the rfc2965 documents this. I think the perl comment is an example for a.b.c.net, so that matchs with .b.c.net but not with b.c.net. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17251 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17251] LWPCookieJar load() set domain_specifed wrong
Maximiliano Curia added the comment: Hi, This is still present in the current mercurial. I'm attaching a patch that fixes the issue. Thanks. -- keywords: +patch nosy: +m...@debian.org versions: +Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file29248/issue_17251.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17251 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17251] LWPCookieJar load() set domain_specifed wrong
Changes by Maximiliano Curia m...@debian.org: Removed file: http://bugs.python.org/file29248/issue_17251.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17251 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4955] xml.sax.expatreader.ExpatParser incorrectly silently skips external character entities in attribute values
Changes by Maximiliano Curia m...@debian.org: -- nosy: +m...@debian.org ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4955 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4955] xml.sax.expatreader.ExpatParser incorrectly silently skips external character entities in attribute values
Maximiliano Curia added the comment:
Hi,
There are two issues commented in this bug, both are part of libexpat.
The one related the code inconsistency is due the design of Xml_Parser.
Reading Modules/expat/xmlparse.c:5036
else if (!entity) {
/* Cannot report skipped entity here - see comments on
skippedEntityHandler.
if (skippedEntityHandler)
skippedEntityHandler(handlerArg, name, 0);
*/
/* Cannot call the default handler because this would be
out of sync with the call to the startElementHandler.
if ((pool == tempPool) defaultHandler)
reportDefault(parser, enc, ptr, next);
*/
break;
}
That's so because libexpat startElementHandler should be called before the
skippedEntityHandler, but this piece of code is processed before the call to
startElementHandler.
To fix this, it would require a change in the libexpat API, adding the concept
of futures to the attributes processing, and a way to obtain them with an
iterator.
In any case, I don't think this is a python issue, but a known libexpat
limitation. It might be forwarded to libexpat developers, but from the python
point of view, it should be closed.
The second issue, is not really an issue. It's the default behaviour if an
entity reference is found but there is no dtd specified (the entities
declaration is a xml extension). This part is working as intended.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4955
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
