# RFC karma request - Thread: https://externals.io/message/119520 - Original archive: https://news-web.php.net/php.internals/119520 - Started by Niels Dossche on 2023-02-11T14:24:15+00:00 - Messages: 7 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #119520 — Niels Dossche — 2023-02-11T14:24:15+00:00 URL: https://externals.io/message/119520#119520 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 --- ## #119525 — Hans Henrik Bergan — 2023-02-12T12:47:32+00:00 URL: https://externals.io/message/119520#119525 · In reply to: #119520 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", 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) > 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 > > -- > > To unsubscribe, visit: https://www.php.net/unsub.php --- ## #119526 — Niels Dossche — 2023-02-12T12:59:25+00:00 URL: https://externals.io/message/119520#119526 · In reply to: #119525 > 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", > > 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) > > > > > > […] > I agree, it's also even more consistent with the other PHP functions, which I like. --- ## #119527 — Thomas Hruska — 2023-02-12T14:46:20+00:00 URL: https://externals.io/message/119520#119527 · In reply to: #119525 > 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) > > > > > > […] -- 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? --- ## #119529 — Hans Henrik Bergan — 2023-02-12T14:59:21+00:00 URL: https://externals.io/message/119520#119529 · In reply to: #119527 Good point, and come to think of it, people wishing to $offset can `fseek()` before before `fpassthru()` anyway. Nevermind the $offset thing, it's more trouble than it's worth ^^ > > > […] > both > > […] > Partial > > […] > > 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. > > > > […] > wrote: > > […] > > > -- > 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? --- ## #119530 — Niels Dossche — 2023-02-12T15:00:52+00:00 URL: https://externals.io/message/119520#119530 · In reply to: #119527 > > > […] > > 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. > > > […] --- ## #119545 — Ilija Tovilo — 2023-02-13T12:46:13+00:00 URL: https://externals.io/message/119520#119545 · In reply to: #119520 Hi Niels > I would like to gain RFC karma for creating and proposing an RFC: "Implement GH-9673: $length argument for fpassthru". > Account name: nielsdos Christoph has granted you RFC karma. Good luck with the RFC! Ilija