[issue2987] RFC2732 support for urlparse (IPv6 addresses)
Changes by Matt Joiner anacro...@gmail.com: -- nosy: +anacrolix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2987 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2987] RFC2732 support for urlparse (IPv6 addresses)
Senthil Kumaran orsent...@gmail.com added the comment: I added an additional invalid test which David pointed out and made changes to invalid url checking code. I moved it more higher level. - The reason for doing this is, invalid url test code (which is very specific for '[' enclosed ']' ipv6 url is concentrated at a single place). We can deal with parsing separately from check. Now, other forms of Invalid URLs are possible as David points out (and possibly more too), but leaving it is better as it would unnecessarily add syntax-checks at various different places (instead of a single place), without much of value add. Dealing with Valid URLs and a parse logic checking should be fine. commits: trunk - r80277 and py3k - r80278 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2987 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2987] RFC2732 support for urlparse (IPv6 addresses)
R. David Murray rdmur...@bitdance.com added the comment: I posted this to the checkins list, but for reference, the following invalid URL should be added to the test cases: http://[::1/foo/bar]/bad -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2987 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2987] RFC2732 support for urlparse (IPv6 addresses)
Senthil Kumaran orsent...@gmail.com added the comment: Moving the Bad URL check to a higher level can be detect the bad urls much better. Once I the netloc is parsed and obtained, invalid URL can be checked. I am attaching an update with the new test included. If you have any comments, please let me know. -- Added file: http://bugs.python.org/file16962/issue2987-bad_url_checks.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2987 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2987] RFC2732 support for urlparse (IPv6 addresses)
R. David Murray rdmur...@bitdance.com added the comment: I don't know how deep you want to get into detecting invalid URIs, but with the new patch this one causes a parsing error that is probably worth dealing with: http://abc[xyz]jkl Maybe a reasonable set of checks would be (in hostname) that if the part of the netloc after the @ contains a ']' or a '[', then it must start with a [ and either end with a ] or contain a ']:'. I can also mess up your new checks with something like this: http://foo[...@baz] or even: http://foo[...@baz:33] although those don't fail, they just faithfully produce the nonsensical results implicit in the invalid urls. I think the above check logic in hostname would catch them, but it wouldn't catch this one: http://foo[...@[bar]:33] That may be OK, though, since as you noted earlier we aren't doing full URI validation. Oh, and I notice that your test only covers the 'fast' path code, it doesn't exercise the general URI logic. (Sorry I didn't review this issue earlier.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2987 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2987] RFC2732 support for urlparse (IPv6 addresses)
Senthil Kumaran orsent...@gmail.com added the comment: Reverted the check-in made to 3.1 maint (in r80104). Features should not go in there. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2987 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2987] RFC2732 support for urlparse (IPv6 addresses)
Senthil Kumaran orsent...@gmail.com added the comment: Final patch with inclusion of detecting invalid urls at netloc and hostname level, tests and NEWS entry. -- Added file: http://bugs.python.org/file16931/issue2987-final.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2987 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2987] RFC2732 support for urlparse (IPv6 addresses)
Benjamin Peterson benja...@python.org added the comment: This is ok with me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2987 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2987] RFC2732 support for urlparse (IPv6 addresses)
Senthil Kumaran orsent...@gmail.com added the comment: Committed into trunk in revision 80101 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2987 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2987] RFC2732 support for urlparse (IPv6 addresses)
Senthil Kumaran orsent...@gmail.com added the comment: merged into py3k in revision 80102 and release31-maint in revision 80103. Thanks for the patches, Tony and Hans. I have acknowledged it in NEWS file too. -- resolution: accepted - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2987 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2987] RFC2732 support for urlparse (IPv6 addresses)
Keegan Carruthers-Smith keegan.csm...@gmail.com added the comment: Just thought I'd point out that RFC2732 was obsoleted by RFC3986 http://www.rfc-editor.org/rfc/rfc3986.txt -- nosy: +Keegan.Carruthers-Smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2987 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2987] RFC2732 support for urlparse (IPv6 addresses)
Éric Araujo mer...@netwok.org added the comment: Hello Thanks for the precision. This particular topic is discussed on #5650, feel free to help there! Better update the code before the doc, though. Regards -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2987 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2987] RFC2732 support for urlparse (IPv6 addresses)
Senthil Kumaran orsent...@gmail.com added the comment: Actually, this bug is just for parsing the IPv6 url. We are having the right set of patches in the bug. I shall commit it soon. The RFC part is separate and we will slowly achieve a good compliance with STD 66. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2987 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2987] RFC2732 support for urlparse (IPv6 addresses)
Senthil Kumaran orsent...@gmail.com added the comment: After spending a sufficient amount of time looking at patches and the RFC 2732, I tend to agree with the patch provided by tlocke. It does cover the behavior for parsing IPv6 URL with '[' hostname ']'. RFC 2732 is very short and just says that hostname in the IPv6 should not have '[' and ']' characters. The patch does just that, which is fine. If hard pressed on detecting invalid IPv6 , I would add and extra +if [ in netloc and ] in netloc: +return netloc.split(])[0][1:].lower() +elif [ in netloc or ] in netloc: +raise ValueError(Invalid IPv6 URL) Which should take care of Invalid IPv6 urls as discussed in this bug. - Any comments on this? Also regarding the urlparse header docs, (it was long pending on me and sorry), here is a patch for current one for review. When we address this bug, I shall include RFC 2732 as well in the list. -- resolution: - accepted Added file: http://bugs.python.org/file16892/urlparse-module-header.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2987 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2987] RFC2732 support for urlparse (IPv6 addresses)
Antoine Pitrou pit...@free.fr added the comment: Isn’t “http://dead:beef::]/foo/“ and invalid URI? That's the point, it shouldn't parse as a valid one IMO. -- title: RFC2732 support for urlparse (e.g. http:// - RFC2732 support for urlparse (IPv6 addresses) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2987 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2987] RFC2732 support for urlparse (IPv6 addresses)
Changes by Tony Locke tlo...@tlocke.org.uk: Removed file: http://bugs.python.org/file16886/parse.py.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2987 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2987] RFC2732 support for urlparse (IPv6 addresses)
Tony Locke tlo...@tlocke.org.uk added the comment: Regarding the RFC list issue, I've posted a new patch with a new RFC list that combines ndim's list and the comments from #5650. Pitrou argues that http://dead:beef::]/foo/ should fail because it's a malformed URL. My response would be that the parse() function has historically assumed that a URL is well formed, and so this change to accommodate IPv6 should continue to assume the URL is well formed. I'd say that a separate bug should be raised if it's thought that parse() should be changed to check that any URL is well-formed. -- Added file: http://bugs.python.org/file16888/parse.py.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2987 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2987] RFC2732 support for urlparse (IPv6 addresses)
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2987 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2987] RFC2732 support for urlparse (IPv6 addresses)
Senthil Kumaran orsent...@gmail.com added the comment: With respect to msg98314 (http://bugs.python.org/msg98314) referenced in this bug, which I thought is easy to handle, does not appear so. It is bit tricky. The problem is the relative url is given of the format '07.11.2009-9:54:12-1.jpg' and urlparse wrongly assumes that it is VALID url with the scheme as 07.11.2009-9 ( Surprisingly, this falls under valid characters for a URL Scheme, but we know that there no url scheme like that). But when you give ./07.11.2009-9, ./ is identified a relative path and urljoin happens properly. My inclination for this specific msg9814, is the allow the user to give the proper path like ./07.11.2009-9 or use urljoin from different directory, images/07.11.2009-9 and this should handle it. This date-time relative url is not a typical scenario, but for typical scnerios, urlparse behaves as expected. x = 'http://a.b.c' urlparse.urljoin(x,'foo') 'http://a.b.c/foo' urlparse.urljoin(x,'./foo') 'http://a.b.c/foo' I shall provide my comments on the IPv6 parse in next msg. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2987 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
