Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119527
Message-ID: <dad6f99d-1b85-0e9e-7311-6170e781a007@cubiclesoft.com>
Date: Sun, 12 Feb 2023 07:46:20 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120327
 Thunderbird/11.0.1
Content-Language: en-US
To: Hans Henrik Bergan <divinity76@gmail.com>,
 Niels Dossche <dossche.niels@gmail.com>
Cc: PHP internals <internals@lists.php.net>
References: <518e7f86-c4b6-c4f5-8e99-8a51ce049738@gmail.com>
 <CAJmy8YH42tD5O9d6pZCb0NFLP0TEhp+go=-cVTtWAa_tQbP25Q@mail.gmail.com>
In-Reply-To: <CAJmy8YH42tD5O9d6pZCb0NFLP0TEhp+go=-cVTtWAa_tQbP25Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC karma request
From: thruska@cubiclesoft.com (Thomas Hruska)

On 2/12/2023 5:47 AM, Hans Henrik Bergan wrote:
> Fwiw I would also find an $offset argument useful. fpassthru's lack of both
> $length and $offset made my life harder when implementing "HTTP 206 Partial
> Content" / "HTTP range requests",

I was going to suggest this myself until I realized that an $offset 
parameter would be rather problematic.  What happens if the offset is 
negative?  Does a negative offset mean seek backwards from the current 
position OR start at that many bytes from the end of the stream?  Is the 
offset a seek operation or a read operation?  Not all streams are 
seekable and reading is generally a fairly slow, blocking I/O operation. 
  Also, not all stream lengths are known.  A negative offset in 
non-seekable scenarios would almost certainly have to throw an error. 
fseek()/fread() are more flexible and consistent for getting to the 
desired starting point in a source stream.

A negative $length would also present some issues.  Again, not all 
stream lengths are known.  Correctly handling negative values would 
require managing an internally, temporarily allocated buffer of 
sufficient size to be able to backtrack streams of unknown length.  And 
might even have to cache the entire stream in RAM, which would be 
problematic for 1GB+ streams.  Or just throw an error for such streams. 
Or just restrict $length to non-negative values only.

In short, a non-negative, nullable $length parameter is the only 
well-defined operation for fpassthru().

fpassthru() is largely a convenience wrapper around fread()/unbuffered 
echo in a loop with some extra output buffer management and is subject 
to PHP max_execution_time.  For large files and/or slow/high latency 
networks, PHP can timeout before delivering all content.

There are several web server extensions available (X-Sendfile and 
X-Accel-Redirect) where, for local files, the rest of the request can be 
handed off from PHP to the web server to completely avoid writing any 
file output to the output buffer and also avoid timeout issues.  The 
existence of modern web server extensions for all major web servers 
limits the overall usefulness of fpassthru().  IMO, $length should be 
added for language-level completeness/convenience but it might also be a 
good idea to mention X-Sendfile/X-Accel-Redirect in the documentation 
for fpassthru() so that users are encouraged to leverage 
resource-efficient technologies wherever possible.


> Ended up with a
> $output = fopen('php://output', 'wb'); + stream_copy_to_stream()
> hack because of fpassthru's shortcomings (Thanks to cmb for that hack, by
> the way)
> 
> 
> On Sat, Feb 11, 2023, 15:26 Niels Dossche <dossche.niels@gmail.com> wrote:
> 
>> Dear internals
>>
>> I would like to gain RFC karma for creating and proposing an RFC:
>> "Implement GH-9673: $length argument for fpassthru".
>> Account name: nielsdos
>>
>> Thanks in advance
>> Kind regards
>> Niels


-- 
Thomas Hruska
CubicleSoft President

CubicleSoft has over 80 original open source projects and counting.
Plus a couple of commercial/retail products.

What software are you looking to build?