Bug 101608

Created attachment 93379 [details]
tgz file contains all

files unpack into a dir named 'files/' (really original, eh?)

The configuration variable:

   php_admin_value post_max_size 30M

is being intepreted as 30 bytes rather than 30 megabytes.  I can't reproduce any
problems if I increase this to 300000 - can you try that?

With the last patch for php at RH 9, this problem of 
   php_admin_value post_max_size 30M
being intepreted as 30 bytes rather than 30 megabytes __seemed_ to have went
away. At earlier patch levels I tripped across this problem with my 'real' web
pages, and quickly substituted 30000000 for 30M -- but still had problems.  I
could post hardly anything at the time _without_ tripping over this problem if
I left the value at 30M.  phpinfo() always showed '30' instead of 30M.

Anyway, with a RH 9 config today, the last patch and a test php script
containing the phpinfo() function, I saw 30M in the output. and thought the
problem gone.

However, I just tested with your suggestion.  All the way down to 5M, and
without testing further down, I have the problem of corrupted post vars.  But
*if* I substitute 5000000 then the problem goes away.  Yuck. It is troubling.
Either way, it's a bug..  At Severn the interpretation of xM seems correct with
my bit of testing.  Thanks for the quick response.

It's late here, and damn hot; and I just read my post again.  I don't know if
it made any sense at all :-{   Anyway, let me try to be more clear.
There are/have-been 2 problems, I guess:
  - in the past I found that you absolutely had to say 30000000 instead of
    30M (for example) in the config file, or nothing worked.  It's a bug.
  - with the last RH 9 php patch, this problem _seemed_ to have disappeared.
    But still I had post-var corruption.  However, with my small test program,
    if I fall back to inserting 30000000 instead of 30M in the file as you
    suggested, then the post-var corruption disappears.  I would need to test
    my real web environment against this, and I will.  But it's still a bug.

However, mow I am wondering if I tested my real web trees adequately with 
both the 30M and 30000000 values.  It is easy to make a boo-boo when you
are trying to isolate the real bug...

I will try to do the rounds again with all these magnificent php-apache 
configuration directives, and see if I can scare up the remaining problem
parameters.

It may seems wierd to some people, but these directives can come in -real- 
handy when you are migrating web trees with wildly different virtual hosts.
For example, in a move from apache1 to apache2, you would want to debug and
secure a web tree, and then move onto the next.  If you can give each virtual
host a wide-open config, and then gradually secure and test them, then you can 
proceed in an orderly fashion, and avoid the big-bang approach to web tree
migration.  Does that make any sense?

Yes, there is a simple off-by-one bug in PHP 4.2 which is causing these config
directives to be misinterpreted, it's fixed in PHP 4.3.  We'll backport the fix
for future 8.0/9 PHP errata.

Created attachment 93397 [details]
fix for the off-by-one bug

This is an updated copy of the php-4.2.2-apache2.patch from the PHP source RPM
which includes the fix for this off-by-one bug.

Thanks for the report.  This is a mass bug update; since this release
of Red Hat Linux is no longer supported, please either:

a) try and reproduce the bug with a supported version of Red Hat
Enterprise Linux or Fedora Core, and re-open this bug as appropriate
after changing the Product field, or,

b) if relevant, try and reproduce this bug using the current version
of the upstream package, and report the bug upstream.

c) report the bug to the Fedora Legacy project who may wish to
continue maintenance of this package.