Hello,

is there somethig new in this case?
Problem seems to be OS dependent. In my case problematical OS is Suse 10.1, others work fine.
Are there some OS-libs i should check?

Thanks,
Andre

I have a server with php running as Fast-cgi (so it's compilled with enable-fastcgi option), and I had the same issue, but I reproduced it when I tried to set memory_limit with 'M/G/K' modificator, and my .htaccess was in Unix format. However it seems, the issue is not related to the option, but it should be in place whether the option exists or not. Please note, I did not try to use it w/o enable-fastcgi option, as the server I use the module on is running FastCGI PHP and it requires the option to be used.

I dug the code and found that the issue was in value_hnd_strip function, here:
  /* strip any leading whitespaces or tabs from the value */
    value_len = strlen(value);
    if (value_len > 2 && value[value_len - 2] == '\r') {
      value[value_len - 2] = 0;
    } else {
      value[value_len] = 0;
    }

Short background: strlen returns length of the string in chars, for example for 'asd' it returns 3. However, 1st char ('a') in the char array (string) has index 0 and the last 'd' in our case has index 2. Index value_len will always point to end of the string mark '\0'.

So, what do we have here? 1st we check, if a string is longer than 2 chars and prelast char of it is '\r' (that's for DOS strings, we're looking for DOS newline '\r\n'), if the expression is true, we replace '\r' (which is start of new line in DOS format) with '\0', i.e truncate DOS new line mark. That works ok. Otherwise, we just try to truncate Unix format new line mark '\n' which is at value_len-1 position in reality, however, instead of replaicing it, we do replace the end of the string mark '\0'.
I solved the problem on my server by applying the patch:
--- htscanner-0.9.0/htscanner.c 2009-03-03 18:00:07.000000000 -0600
+++ htscanner.c.correct 2010-01-13 06:47:14.000000000 -0600
@@ -189,7 +189,7 @@
                if (value_len > 2 && value[value_len - 2] == '\r') {
                        value[value_len - 2] = 0;
                } else {
-                       value[value_len] = 0;
+                       value[value_len - 1] = 0;
                }

                /* strip quoting characters */


But as I told I did not test it without enable-fastcgi option set. I admit, that in some cases, behaviour of file read functions in php can be different (in some cases it returns strings with \r\n, but in some w/o). To avoid the issue in the future I would replace this code block with completely new one:
        /* strip any trailing whitespaces or tabs from the value */
        value_len = 0;
        while (((value_len = strlen(value)) > 0) && ((value[value_len - 1] == '\r')||(value[value_len - 1] == '\n')))
                value[value_len - 1] = 0;

A little addon:
Server I had the problem is running Centos 5.4, PHP 5.2.12.

Also, if you decide to use code I gave, it's easy to add there tabs, spaces, quotes and d-quotes (which is supposed to be there according to the comment):

        /* strip any trailing whitespaces or tabs from the value */
        value_len = 0;
        while (((value_len = strlen(value)) > 0) && ( \
			(value[value_len - 1] == '\r')|| \
			(value[value_len - 1] == '\n')|| \
			(value[value_len - 1] == '\t')|| \
			(value[value_len - 1] == '"') || \
			(value[value_len - 1] == '\'')|| \
		))
		value[value_len - 1] = 0;

I did mistake on the code I posted last night (it was too late, early morning actually :)), thanks Andre for notice. Moreover, we should not remove trailing quotas there as well. However, actually, that block was "proof of concept code", which goal was - illustrate my idea.

Now, I prepared real patch which I have tested on my server. You may download it here:
http://yourserveradmin.com/ik/htscanner-0.9.0.eol.patch

Detailed info for developers of how they can reproduce the problem:

1. .htaccess file:
php_value post_max_size '32M'
php_value memory_limit 128M
php_value upload_max_filesize "64M"

2. ini_get.php script:
<?php

echo "'post_max_size = " . ini_get('post_max_size') . "'\n";
echo "'memory_limit = " . ini_get('memory_limit') . "'\n";
echo "'upload_max_filesize = " . ini_get('upload_max_filesize') . "'\n";
?>

3. If I open the script with original code I get:
'post_max_size = '32M'
'
'memory_limit = 128M
'
'upload_max_filesize = "64M"
'

As you can see EOLs were not removed, and due to this trailing quotas couldn't be found and therefore, quotas were not removed too

4. After patch applying:
'post_max_size = 32M'
'memory_limit = 128M'
'upload_max_filesize = 64M'

All works as expected.

last version is working correct.
Thanks for fixing,
Andre

This Bug breaks the behavior with php_flag in cgi-mode.

.htaccess
===
php_flag short_open_tag On
==
dos2unix .htaccess -> short_open_tag=0
unix2dos .htaccess -> short_open_tag=1

I confirm that patch from "ik at yourserveradmin dot com" is mandatory to have a usable extension with php-cgi (php 5.2.6). Without it, php_value and php_flag are totally and silently broken.
php_value will store value with a \n, which silently break some (all ?) configuration values (and PHP does not complain)
php_flag with value "On" or "1" never matches in function value_hnd and are always set to "0"

The htscanner parser code has been rewritten in trunk.