phpBB intends to give plupload a chunk_size configuration that is "within the bounds of the involved phpBB and PHP limits."  And in fact, is aiming to be "well within these limits", by using a value that is half of whatever maximum value could have been used.  This is calculated in the get_chunk_size() function of /phpbb/plupload/plupload.php:

	public function get_chunk_size()

	{

		$max = min(

			$this->php_ini->getBytes('upload_max_filesize'),

			$this->php_ini->getBytes('post_max_size'),

			max(1, $this->php_ini->getBytes('memory_limit')),

			$this->config['max_filesize']

		);

		// Use half of the maximum possible to leave plenty of room for other

		// POST data.

		return floor($max / 2);

	}

 
If PHP's upload_max_filesize is set to zero, or PHP's post_max_size is set to zero, or if phpBB's own max_filesize is set to zero, then the "0" value automatically wins all the min() tests. Even though "0" in this case means "huge value", and not "smallest value." The only "unlimited" value protected from creating this result was the PHP memory_limit configuration.

I confirmed this on my PHP 7.2.19 phpBB 3.2.7 board, where the involved PHP configurations are "post_max_size: 32M" , "upload_max_filesize: 32M" and "memory_limit: 128M". So phpBB's intention would have been to tell plupload to not chunk any higher than 16MB.

But because my phpBB max_filesize limit is 0 (unlimited), the rendered /styles/prosilver/template/plupload.html template ends up giving plupload a configuration of "max_file_size: '0b'" and "chunk_size: '0b'".

As such, when I attempt to upload a file which is in excess of 32MB, I end up hitting the PHP "post_max_size: 32M" or "upload_max_filesize: 32M" limit which causes a plupload failure.  Instead of being safely chunked to the intended unlimited upload file size.

Recommend that the PHP upload_max_filesize value, and the PHP post_max_size value, and the phpBB max_filesize value be protected within the get_chunk_size() calculations from being allowed to arrive at a "zero" result.