Hi,
I want to deal with Bug 44522 which disallows uploads > 2G
https://bugs.php.net/bug.php?id=44522&edit=1
Today with PHP cloud solutions, we are running into more situations
where this really hurts.
Before I begin providing a github patch (as I have no php svn access and
I don't think it's needed) against master and possibly 5.5.next:
Does anybody know of intricate reasons why the existing patch
could not be included into php 5.5?
Or is it only what stas said in 2012:
"The patch however
needs to be cleaned up (no IGNORE vars, etc.) and changing signature for
zend_atoi may not be safe if any code out there presumes it returns int
(integer
overflow). Also, no reason to use signed long there where we used
unsigned long."
This would be my first patch against php core. Any pointers apreciated.
--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Hi,
Hi,
I want to deal with Bug 44522 which disallows uploads > 2G
https://bugs.php.net/bug.php?id=44522&edit=1
Great!
Today with PHP cloud solutions, we are running into more situations
where this really hurts.
Yay cloud :-D
(i don't see why cloud matters, here though it's more about modern
bandwidth and storage space)
Before I begin providing a github patch (as I have no php svn access and
I don't think it's needed) against master and possibly 5.5.next:Does anybody know of intricate reasons why the existing patch
could not be included into php 5.5?
Most likely since nobody cared enough and pushed it. (both, pushed in
the tree and pushed as in making people aware)
Unfortunately the patch can't make it in 5.5. It changes the size and
offsets in the sapi globals which breaks binary compatibility which we
can't do in a dot release. Has to be 5.6/PHP.next.
I haven't looked close enough to comment on the patch itself.
johannes
Yay cloud :-D
(i don't see why cloud matters, here though it's more about modern
bandwidth and storage space)
Just did not want to name the product which prompted me to finally go at
it. ;)
Before I begin providing a github patch (as I have no php svn access and
I don't think it's needed) against master and possibly 5.5.next:Does anybody know of intricate reasons why the existing patch
could not be included into php 5.5?
Most likely since nobody cared enough and pushed it. (both, pushed in
the tree and pushed as in making people aware)Unfortunately the patch can't make it in 5.5. It changes the size and
offsets in the sapi globals which breaks binary compatibility which we
can't do in a dot release. Has to be 5.6/PHP.next.I haven't looked close enough to comment on the patch itself.
OK, no 5.5 then.
Anyway, I have built a version of the patch (using unsigned long instead
of signed long as the original did) against old php 5.3.8 and currently
a test is running with a 4.7 GiB DVD Image. If it works well, I will
submit the patch and attach it to the bug record.
Thank you for your response.
--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Anyway, I have built a version of the patch (using unsigned long instead
of signed long as the original did) against old php 5.3.8 and currently
a test is running with a 4.7 GiB DVD Image. If it works well, I will
submit the patch and attach it to the bug record.Thank you for your response.
To make it more reviewable, can you base the patch on the master
branch (aka PHP 5.6)? If you're a github user, a PR would be great.
Some supporting documentation about what the patch changes, what
platforms it was tested on etc would be helpful. I think a brief RFC
would be the best place to record the details: https://wiki.php.net/rfc/howto
Did you review all the previous mail list discussion about the patch?
IIRC there were a bunch of reasons it never got merged.
Chris
--
christopher.jones@oracle.com http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
Did you review all the previous mail list discussion about the patch?
IIRC there were a bunch of reasons it never got merged.
what we never merged for reasons is large file support. So 32bit
machines can use files >2G. The patches there open a can of worm with
libraries/environments we link to and where we might exchange file
pointers.
Besides the binary compatibility and required review and testing there
is no such reason here. The biggest issue here is that people might be
careful about changing request handling as that's quite central to PHP
and a bug there can lead to remote exploitable bugs, but doing this
early, like now for 5.6, should be fine.
joahnnes
Anyway, I have built a version of the patch (using unsigned long instead
of signed long as the original did) against old php 5.3.8 and currently
a test is running with a 4.7 GiB DVD Image. If it works well, I will
submit the patch and attach it to the bug record.Thank you for your response.
To make it more reviewable, can you base the patch on the master
branch (aka PHP 5.6)? If you're a github user, a PR would be great.
Done that.
https://github.com/php/php-src/pull/372
Did you review all the previous mail list discussion about the patch?
IIRC there were a bunch of reasons it never got merged.
I read the bug report discussion, stas' mails and what I found in the
archives. I might have missed information though.
--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Anyway, I have built a version of the patch (using unsigned long instead
of signed long as the original did) against old php 5.3.8 and currently
a test is running with a 4.7 GiB DVD Image. If it works well, I will
submit the patch and attach it to the bug record.Thank you for your response.
To make it more reviewable, can you base the patch on the master
branch (aka PHP 5.6)? If you're a github user, a PR would be great.Done that.
https://github.com/php/php-src/pull/372Did you review all the previous mail list discussion about the patch?
IIRC there were a bunch of reasons it never got merged.I read the bug report discussion, stas' mails and what I found in the
archives. I might have missed information though.
Any additional action required from my side or is it just waiting for a
review timeslot?
--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Any additional action required from my side or is it just waiting for a
review timeslot?
I'll soon be able to merge/align it with a solution that's been
running in production for years, just give me a few days. Thank you
for your patience!
--
Regards,
Mike
I have added a simple test case for Linux to verify it's basic
functionality via the CLI server, and think it's ready to be merged to
master to be able to test it within a wider audience.
Objections, anyone?
https://github.com/m6w6/php-src/compare/2Guploads
Thank you Ralf!
--
Regards,
Mike
I have added a simple test case for Linux to verify it's basic
functionality via the CLI server, and think it's ready to be merged to
master to be able to test it within a wider audience.Objections, anyone?
https://github.com/m6w6/php-src/compare/2Guploads
Johannes reminded me, that we don't have C99 stdint portable typedefs
in a central PHP header file available yet.
--
Regards,
Mike
Hi Mike,
I have added a simple test case for Linux to verify it's basic
functionality via the CLI server, and think it's ready to be merged to
master to be able to test it within a wider audience.Objections, anyone?
https://github.com/m6w6/php-src/compare/2GuploadsJohannes reminded me, that we don't have C99 stdint portable typedefs
in a central PHP header file available yet.
In 5.3+ it is easier. Other parts of php deals with that. M4 Macros are
there for unices, on windows you have php_stdint (which transparently
includes stdint with vc11 and up).
--
Regards,
Mike
Hi Mike,
I have added a simple test case for Linux to verify it's basic
functionality via the CLI server, and think it's ready to be merged to
master to be able to test it within a wider audience.Objections, anyone?
https://github.com/m6w6/php-src/compare/2GuploadsJohannes reminded me, that we don't have C99 stdint portable typedefs
in a central PHP header file available yet.In 5.3+ it is easier. Other parts of php deals with that. M4 Macros are
there for unices, on windows you have php_stdint (which transparently
includes stdint with vc11 and up).
Yes, Anatol gave quite a few comments on the PR, so I knew about
win32/php_stdint.h, but I was tricked by my memory about a globally
(PHP-wide) available portability header :)
Thanks for the heads up though!
--
Regards,
Mike
Hi Mike,
Johannes reminded me, that we don't have C99 stdint portable typedefs
in a central PHP header file available yet.In 5.3+ it is easier. Other parts of php deals with that. M4 Macros are
there for unices, on windows you have php_stdint (which transparently
includes stdint with vc11 and up).Yes, Anatol gave quite a few comments on the PR, so I knew about
win32/php_stdint.h, but I was tricked by my memory about a globally
(PHP-wide) available portability header :)
Alright, I rebased the 2Gupload branch against stdint:
https://github.com/m6w6/php-src/compare/2Guploads
https://github.com/m6w6/php-src/compare/stdint
A test build on more exotic platforms would be appreciated -- I'm
working on setting some up for me.
Thank you.
--
Regards,
Mike
Alright, I rebased the 2Gupload branch against stdint:
https://github.com/m6w6/php-src/compare/2Guploads
https://github.com/m6w6/php-src/compare/stdint
So, is everyone fine with it so far?
--
Regards,
Mike
Alright, I rebased the 2Gupload branch against stdint:
https://github.com/m6w6/php-src/compare/2Guploads
https://github.com/m6w6/php-src/compare/stdintSo, is everyone fine with it so far?
I'm fine with this. Juggling around with types to get a crossplatform
64bit type was not so easy for me.
--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Hi Michael
2013/8/8 Michael Wallner mike@php.net:
Alright, I rebased the 2Gupload branch against stdint:
https://github.com/m6w6/php-src/compare/2Guploads
https://github.com/m6w6/php-src/compare/stdintSo, is everyone fine with it so far?
I think it is a long overdue that we have not have had this patch or
similar committed, so I would say go a head and commit it to master.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Hi Michael
2013/8/8 Michael Wallner mike@php.net:
Alright, I rebased the 2Gupload branch against stdint:
https://github.com/m6w6/php-src/compare/2Guploads
https://github.com/m6w6/php-src/compare/stdintSo, is everyone fine with it so far?
I think it is a long overdue that we have not have had this patch or
similar committed, so I would say go a head and commit it to master.
Thought so. I'll merge tomorrow.
--
Regards,
Mike
Hi
Just a comment for the patch.
2013/6/27 Ralf Lang lang@b1-systems.de
Does anybody know of intricate reasons why the existing patch
could not be included into php 5.5?
It uses long instead of uint but it makes large files available only to
64bit platforms.
It should use off_t along with "#define _FILE_OFFSET_BITS 64", but I'm not
sure if this work under windows. There may be other places that data type
should be changed. It should be checked carefully, otherwise memory fault
may occur due to integer overflow.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
To be fair, the overall limit is going to be 32 bit anyway (due to the use
of int for string lengths)...
I'm working on a patch to replace all references of string sizes with
size_t, but as you can imagine, it's going to take some time...
Just throwing it out there that a better fix may be coming down the road
anyway. I'll post on-list in the coming days about this...
Anthony
Hi
Just a comment for the patch.
2013/6/27 Ralf Lang lang@b1-systems.de
Does anybody know of intricate reasons why the existing patch
could not be included into php 5.5?
It uses long instead of uint but it makes large files available only to
64bit platforms.It should use off_t along with "#define _FILE_OFFSET_BITS 64", but I'm not
sure if this work under windows. There may be other places that data type
should be changed. It should be checked carefully, otherwise memory fault
may occur due to integer overflow.Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
To be fair, the overall limit is going to be 32 bit anyway (due to the use
of int for string lengths)...
For file uploads? Why? We never hold the entire file in a string.
-Rasmus
Hey:
Instead of change the uint to long or size_t, Maybe make the
max_file_upload_size 0 means unlimited? like Apached did, ulimited or
<= 2Gb
https://httpd.apache.org/docs/2.2/mod/core.html#limitrequestbody
thanks
Hi,
I want to deal with Bug 44522 which disallows uploads > 2G
https://bugs.php.net/bug.php?id=44522&edit=1Today with PHP cloud solutions, we are running into more situations
where this really hurts.Before I begin providing a github patch (as I have no php svn access and
I don't think it's needed) against master and possibly 5.5.next:Does anybody know of intricate reasons why the existing patch
could not be included into php 5.5?
Or is it only what stas said in 2012:
"The patch however
needs to be cleaned up (no IGNORE vars, etc.) and changing signature for
zend_atoi may not be safe if any code out there presumes it returns int
(integer
overflow). Also, no reason to use signed long there where we used
unsigned long."This would be my first patch against php core. Any pointers apreciated.
--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
--
Laruence Xinchen Hui
http://www.laruence.com/
Hey:
Instead of change the uint to long or size_t, Maybe make the
max_file_upload_size 0 means unlimited? like Apached did, ulimited or
<= 2Gb
s ,Gb,GB,
https://httpd.apache.org/docs/2.2/mod/core.html#limitrequestbody
thanks
Hi,
I want to deal with Bug 44522 which disallows uploads > 2G
https://bugs.php.net/bug.php?id=44522&edit=1Today with PHP cloud solutions, we are running into more situations
where this really hurts.Before I begin providing a github patch (as I have no php svn access and
I don't think it's needed) against master and possibly 5.5.next:Does anybody know of intricate reasons why the existing patch
could not be included into php 5.5?
Or is it only what stas said in 2012:
"The patch however
needs to be cleaned up (no IGNORE vars, etc.) and changing signature for
zend_atoi may not be safe if any code out there presumes it returns int
(integer
overflow). Also, no reason to use signed long there where we used
unsigned long."This would be my first patch against php core. Any pointers apreciated.
--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537--
Laruence Xinchen Hui
http://www.laruence.com/
--
Laruence Xinchen Hui
http://www.laruence.com/
Hey:
Instead of change the uint to long or size_t, Maybe make the
max_file_upload_size 0 means unlimited? like Apached did, ulimited or
<= 2Gbhttps://httpd.apache.org/docs/2.2/mod/core.html#limitrequestbody
This doesn't change the behaviour that the user sets a size and is not
notified that indeed a much lower (overflowed) size is configured.
--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537