|   | php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login | 
| 
 Patchesbig-content-length.patch (last revision 2010-08-23 19:48 UTC by dominic dot benson at thirdlight dot com)Pull RequestsHistoryAllCommentsChangesGit/SVN commits              [2010-08-23 21:49 UTC] dominic dot benson at thirdlight dot com
  [2010-08-24 13:17 UTC] johannes@php.net
  [2010-08-24 13:32 UTC] pajoye@php.net
 
-Status:      Open
+Status:      Assigned
-Assigned To:
+Assigned To: pajoye
  [2010-08-24 13:32 UTC] pajoye@php.net
  [2017-10-24 07:32 UTC] kalle@php.net
 
-Status:      Assigned
+Status:      Open
-Assigned To: pajoye
+Assigned To:
  [2021-07-20 13:03 UTC] cmb@php.net
 
-Status:      Open
+Status:      Closed
-Assigned To:
+Assigned To: cmb
  [2021-07-20 13:03 UTC] cmb@php.net
 | |||||||||||||||||||||||||||||||||||||
|  Copyright © 2001-2025 The PHP Group All rights reserved. | Last updated: Fri Oct 31 10:00:02 2025 UTC | 
Description: ------------ As per #51723, the content-length header is limited to 2GB - however it need not be. If Apache 2.2 is built with -DLARGEFILE_SOURCE -DFILE_OFFSET_BITS=64 then apr_off_t is an off64_t, however the conversion in the calls to ap_set_content_length uses strtocol (hence limited to the 32-bit long on Linux 32), but if strtocoll is used instead to return a 64-bit long long, the header is set correctly for values > 2GB. The attached patch is of the adjustment, I guess the configure script generation needs to be updated to establish whether apr_off_t is long or long long. Test script: --------------- <?php header("Content-Length: 10000000000"); ?> Expected result: ---------------- A header: Content-Length: 10000000000 Actual result: -------------- A header: Content-Length: 2147483647