php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #39927 server variable names are silently changed
Submitted: 2006-12-22 00:28 UTC Modified: 2008-08-30 16:54 UTC
From: to_devnull at yahoo dot com Assigned:
Status: Closed Package: Apache related
PHP Version: 5.2.0 OS: all
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: to_devnull at yahoo dot com
New email:
PHP Version: OS:

 

 [2006-12-22 00:28 UTC] to_devnull at yahoo dot com 
Description:
------------
I'm "reopening" Bug #13961 since some moron marked it as "bogus" and I can't comment on it:
http://bugs.php.net/bug.php?id=13961

Apache module mod_setenvif sets variables in 
r->subprocess_env. If variable name contains character ".", then sapi_apache_register_server_variables() will
replace it with "_". This breaks internal
variables like force-response-1.0 (php changes it to
force-response-1_0).

I hit this bug with PHP4.4.3/PHP5 and latest Apache 1.3.37. Spent several hours tracing in debugger why "downgrade-1.0" becomes "downgrade-1_0". This is a serious bug -- basically it's impossible to downgrade client request/server response to HTTP 1.0 (or disable chunking) if php is involved. What a shame!


Reproduce code:
---------------
I actually traced it by shoving a static string containing '.' in r->subprocess_env and thus getting Apache to core dump when php tries to write to read-only memory in php_register_variable_ex().

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-12-22 03:34 UTC] iliaa@php.net 
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

This is legacy of register_globals, as long as it exists . and 
spaces in input var names will be converted to underscores.
 [2006-12-22 21:58 UTC] to_devnull at yahoo dot com 
This a strange reply ("Read a manual, this is not a bug").
Am I doing anything wrong here? I'm using default php installation and register_globals is Off in php.ini. Is there a way to configure php not to touch values in r->subprocess_env?
My point is that php silently breaks Apache behavior by modifying specific data that is supposed to be read-only.
If Apache allows "force-response-1.0" in its subprocess_env table, why php changes it? If php wants to modify input var names, it should make a copy.
I may be totally wrong and miss some important configuration issue. In this case I'd greatly appreciate if you point me in the right direction. But canned response is not an answer.
 [2006-12-23 00:58 UTC] judas dot iscariote at gmail dot com 
Ilia:

This behaviour is pretty much broken, why it does not check when register_globals is disabled and behaves correctly ?
(and maybe drop register_globals in 5.3 or asap will be nice too ;) )
 [2006-12-23 01:26 UTC] rasmus@php.net 
I think the answer to that should be pretty obvious.  We don't want to change behaviour of the code with and without register_globals.  An app would have to check the register_globals setting in order to determine what the variable is called.  That's even more confusing than the current situation where it is simply consistently changed.  Once you realize that server variables may not contain spaces or dots, it is quite straightforward to write code against that.

In fact, even when register_globals is completely removed, I doubt this will change since it would break backward compatibility with all existing apps.
 [2008-08-30 16:54 UTC] rasmus@php.net 
Fixed in 5.2, 5.3 and 6 CVS
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sun Dec 22 05:01:30 2024 UTC