Re: RFC karma request

On 12/02/2023 15:46, Thomas Hruska wrote: > 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 offset would not be valid, just like it is not valid for stream_copy_to_stream. The offset is a seek operation just like is the case for stream_copy_to_stream. Not all streams are seekable that's true, but the programmer using the changed fpassthru function would have the same issue if they were to use fseek or stream_copy_to_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(). > The behaviour of a negative $length would be the same as for stream_copy_to_stream. The current behaviour for negative lengths < -1 is to interpret them as unsigned lengths. For lengths == -1 the behaviour is to copy everything. I don't see how this is different from for example very large lengths and an unknown stream length. I don't really understand your concern here. Could you please elaborate on the problem you see? > 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. > I agree it's a good idea to add this to the manual, although it should be noted that not every place where PHP is provided for hosting has this functionality available. > >> 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 > >