Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89460
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.50 as permitted sender)
MIME-Version: 1.0
References: <CAF+90c_pVFVbzqThuPg1V3VDTV-7Ci4O6T6hNtY5XPgVb2Mt-Q@mail.gmail.com>
In-Reply-To: <CAF+90c_pVFVbzqThuPg1V3VDTV-7Ci4O6T6hNtY5XPgVb2Mt-Q@mail.gmail.com>
Date: Fri, 27 Nov 2015 08:44:36 +0000
Message-ID: <CAPwsocHovxRs-7pW_V2gCdgxMzjt2tO2Z=GT0MMSu+YGKEUtFQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>, 
	Anatol Belski <anatol.php@belski.net>, Remi Collet <remi@php.net>
Content-Type: multipart/alternative; boundary=047d7b5d49760f119f052581b439
Subject: Re: [PHP-DEV] HashDos protection
From: leight@gmail.com (Leigh)

--047d7b5d49760f119f052581b439
Content-Type: text/plain; charset=UTF-8

On Thu, 26 Nov 2015 at 17:25 Nikita Popov <nikita.ppv@gmail.com> wrote:

> This will throw a fatal error if the number of
> collisions during an insertion operation exceed a certain threshold.
>

To me this feels like it's just moving a DoS vector from one place to
another.

As Niklas already pointed out, he is directly affected by this.

I was considering the scenario:
1) Open resources
2) json_decode
3) Do stuff
4) Clean up resources

This makes the DoS more application specific, but there's any number of
creative uses for making an application unexpectedly fail half way through.

You can argue it's similar to any DoS that causes a request to run out of
memory half way through, it is in some ways.

I don't think an exception is right for this either. People blindly catch
all exceptions because they can.

Not sure what to suggest.

--047d7b5d49760f119f052581b439--