|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #58909 seems that htscanner is adding an linebreak to path-values when using php-cgi
Submitted: 2009-10-21 10:25 UTC Modified: 2010-11-21 20:18 UTC
From: andre dot huebner at gmx dot de Assigned: martynas (profile)
Status: Closed Package: htscanner (PECL)
PHP Version: 5.2.11 OS: Suse 10.1
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: andre dot huebner at gmx dot de
New email:
PHP Version: OS:


 [2009-10-21 10:25 UTC] andre dot huebner at gmx dot de
seems that htscanner is adding a linebreak to path-values when php is compiled for fastcgi (--enable-fastcgi)
mod_php, php_cli works fine, just php-cgi is the exception...


php_value session.save_path /path/to/path/to/path

Reproduce code:
echo ini_get("session.save_path")."<==";

Expected result:

Actual result:


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-12-03 05:23 UTC] andre dot huebner at gmx dot de

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?

 [2010-01-17 21:39 UTC] ik at yourserveradmin dot com
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;
 [2010-01-17 21:50 UTC] ik at yourserveradmin dot com
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;
 [2010-01-18 17:52 UTC] ik at yourserveradmin dot com
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:

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:

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.
 [2010-01-19 03:44 UTC] andre dot huebner at gmx dot de
last version is working correct.
Thanks for fixing,
 [2010-10-08 11:05 UTC] andy at boeckler dot org
This Bug breaks the behavior with php_flag in cgi-mode.

php_flag short_open_tag On
dos2unix .htaccess -> short_open_tag=0
unix2dos .htaccess -> short_open_tag=1
 [2010-10-14 06:09 UTC] julien dot ozog+pecl at ixene dot net
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"
 [2010-11-21 20:18 UTC] martynas at venck dot us
The htscanner parser code has been rewritten in trunk.
PHP Copyright © 2001-2018 The PHP Group
All rights reserved.
Last updated: Sun Nov 19 01:31:42 2017 UTC