Bug #45945 [Opn->Nab]: Apache byterange output filter nullified if mod_php5 output > 8000 bytes

Edit report at https://bugs.php.net/bug.php?id=45945&edit=1 ID: 45945 Updated by: cmb@php.net Reported by: djimenez at conduit-it dot com Summary: Apache byterange output filter nullified if mod_php5 output > 8000 bytes -Status: Open +Status: Not a bug Type: Bug Package: Apache2 related Operating System: Ubuntu PHP Version: 5.*, 6CVS (2009-07-15) -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: I can confirm the reported behavior. However, doing the same request without Range header sheds some light on what's happening, namely that Apache buffers up to 8000 bytes, and if that buffer is not full at the end of the request, a plain payload and a Content-Length header are sent. But if the buffer is full, Apache sends a chunked payload and the respective Transfer-Encoding header, so the Range request is ignored, what is permissible according to RFC 7233[2]. You can increase the default buffer size by using mod_buffer[1], if you desire so. However, the proper solution is to handle Range request yourself, where sensible. It doesn't make sense to actually send a large payload to the Web server, and to let the Web server only send a small part of that to the client. Instead, just send the requested part to Apache in the first place. Make sure that Apache's buffer is large enough, and respond with a proper 416 otherwise. [1] <https://httpd.apache.org/docs/trunk/mod/mod_buffer.html> [2] <https://httpwg.org/specs/rfc7233.html#header.range> Previous Comments: ------------------------------------------------------------------------ [2020-09-13 11:51:26] masterofsql at emailfromgoogle dot com I hope someone will find this useful EXPLICITLY adding header("Transfer-Encoding: chunked"); solved the problem (not sure how reliably though). That Transfer-Encoding header was being added automatically even if i didn't set it - but the problem was there. Adding the header explicitly in PHP code solved it. Tested using websniffer.cc, PHP 7.4.9 CentOS 7.8 ------------------------------------------------------------------------ [2012-11-15 11:49:09] richard_s_yeo at hotmail dot com Has there been any update to this? I am experiencing the same issue on Windows and Linux with 5.3.5 of php. This is a very important issue for me and the workaround of using redirect won't work for me. ------------------------------------------------------------------------ [2010-03-24 10:02:46] thwien at gmx dot net I can confirm this problem. Exactly over 8000 Bytes it does not work anymore. Also using the Apache module x-sendfile does not solve this error in my case. The one and only work-around in my case is a header call with location of a static url. header('Location: http://any.url/toanyfile.html'); exit; After this just Apache controls the range operator and it works as expected. ------------------------------------------------------------------------ [2009-10-13 21:30:08] dylan at io dot com I have found that using sing X-Sendfile will solve this issue: http://tn123.ath.cx/mod_xsendfile/ (at least for Apache/mod_php). Also even if this "bug" was fixed, I'm not sure the results would be very desirable. Since there's no way to efficiently "fseek" to a particular byte in the script output, I assume mod_php would have to transfer the entire document internally for each chunk that was requested. ------------------------------------------------------------------------ [2009-09-16 14:15:21] djimenez at conduit-it dot com Using the handler module: LoadModule php5_module /usr/lib/apache2/modules/libphp5.so <IfModule mod_php5.c> AddType application/x-httpd-php .php .phtml .php3 .html .inc .func .clss AddType application/x-httpd-php-source .phps </IfModule> ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=45945 -- Edit this bug report at https://bugs.php.net/bug.php?id=45945&edit=1