Re: [Python-Dev] Adding a maximum element count to parse_qs?
On Mon, 13 Feb 2012 00:32:07 +0100 mar...@v.loewis.de wrote: > >> No, you are missing my point. I assume you proposed (even though you > >> didn't say so explicitly) that parse_qs gets an opt-in API change to > >> limit the number of parameters. If that is added, it will have no > >> effect on any existing applications, as they will all currently not > >> pass that parameter. > > > > No, I said it would include a default value of (say) 1000 parameters. > > That default value would be applied to anyone doesn't use the new API. > > (the reason I'm proposing a new API is to allow people to change or > > disable the limit, in case they really want to pass a large number of > > parameters) > > I see. -1 on that proposal, then: there are certainly applications that will > break with that. I don't find 1000 POST parameters a lot, and I'm sure that > people use that in a programmatic fashion (e.g. to mass-upload stuff). > > If you really think that kind of change is necessary, develop a separate patch > that people who are worried can apply. Fair enough. Actually, people can simply call parse_qsl and check the len() of the returned list before stuffing the params into a dict. That said, we can still do the change (without any limiting default value) for 3.3. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding a maximum element count to parse_qs?
No, you are missing my point. I assume you proposed (even though you didn't say so explicitly) that parse_qs gets an opt-in API change to limit the number of parameters. If that is added, it will have no effect on any existing applications, as they will all currently not pass that parameter. No, I said it would include a default value of (say) 1000 parameters. That default value would be applied to anyone doesn't use the new API. (the reason I'm proposing a new API is to allow people to change or disable the limit, in case they really want to pass a large number of parameters) I see. -1 on that proposal, then: there are certainly applications that will break with that. I don't find 1000 POST parameters a lot, and I'm sure that people use that in a programmatic fashion (e.g. to mass-upload stuff). If you really think that kind of change is necessary, develop a separate patch that people who are worried can apply. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding a maximum element count to parse_qs?
On Mon, 13 Feb 2012 00:08:45 +0100 mar...@v.loewis.de wrote: > > >> b) of limited use for existing installations which won't use the API. > > > > Obviously it won't fix vulnerabilities due to some other API. If you > > propose other APIs we can also fix them. > > No, you are missing my point. I assume you proposed (even though you > didn't say so explicitly) that parse_qs gets an opt-in API change to > limit the number of parameters. If that is added, it will have no > effect on any existing applications, as they will all currently not > pass that parameter. No, I said it would include a default value of (say) 1000 parameters. That default value would be applied to anyone doesn't use the new API. (the reason I'm proposing a new API is to allow people to change or disable the limit, in case they really want to pass a large number of parameters) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding a maximum element count to parse_qs?
It's an API change, so it is a) in violation with current practice for bug fix releases, and We are already violating a lot of things in order to fix this issue. Not really. There isn't any significant API change in the proposed patch (the ones that are there are safe to ignore in applications). There is, of course, a major behavior change, but that is deliberately opt-in. b) of limited use for existing installations which won't use the API. Obviously it won't fix vulnerabilities due to some other API. If you propose other APIs we can also fix them. No, you are missing my point. I assume you proposed (even though you didn't say so explicitly) that parse_qs gets an opt-in API change to limit the number of parameters. If that is added, it will have no effect on any existing applications, as they will all currently not pass that parameter. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding a maximum element count to parse_qs?
On Sun, 12 Feb 2012 21:44:22 +0100 "Martin v. Löwis" wrote: > > Given the randomization fix will ship disabled, I thought it would be > > nice to add a maximum element count argument to urlparse.parse_qs, with > > a default value of e.g. 1000 (including in bugfix releases). What do > > you think? > > It's an API change, so it is > a) in violation with current practice for bug fix releases, and We are already violating a lot of things in order to fix this issue. > b) of limited use for existing installations which won't use the API. Obviously it won't fix vulnerabilities due to some other API. If you propose other APIs we can also fix them. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding a maximum element count to parse_qs?
> Given the randomization fix will ship disabled, I thought it would be > nice to add a maximum element count argument to urlparse.parse_qs, with > a default value of e.g. 1000 (including in bugfix releases). What do > you think? It's an API change, so it is a) in violation with current practice for bug fix releases, and b) of limited use for existing installations which won't use the API. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
